Re: [RP] A big set of changes [patch included]

[Ryan Yeske]

Gergely Nagy <address@hidden> writes:

> Hi!
> 
> I was poking around in the ratpoison sources, and found that there
> are still some char winname[100]; -like thing (for example in
> src/actions.c. In src/actions.c's case, most of it is there because
> of get_input(). From that I deduce that get_input() only accepts a
> static number of chars, but that's not good. Wouldn't it be better
> if get_input() would automagically reallocate its input buffer and
> return that ?

Yes, it was on my list of things to do.  Having a patch sent to the
list is much better though :)
 
> So, instead of
> 
> void get_input (screen_info *s, char *prompt, char *str, int len);
> 
> We'd have
> 
> char *get_input (screen_info *s, char *prompt );
 
Yup.  We could dump the screen_info param too, as in most of the calls
its supplied with get_screen().  It might as well be in the
get_input() call.

> A diff that converts all get_input() using things to the new interface
> is attached to this mail. It also changes some fprintf(stderr, ...)s
> to PRINT_DEBUG()s. It also contains other changes, see the ChangeLog,
> or the diff itself :)
> 
> After this change, only one static buffer exists in the ratpoison
> code, and I cannot fix that.

Which one is that?  Why can't you fix it? :)
 
> If no-one objects to it, I'll commit my changes within a few minutes.

I kinda looked at your patch but found it hard to read.  There are
also a lot of formatting and copyright updates etc in the patch (which
you mentioned).  This makes is more difficult to assess the code
changes.

Also, why the change from the header protect style of

#ifndef FOO
#define FOO

to:

#ifndef FOO
#define FOO 1
...
 
Style preference?  Portability?

> Oh! Shawn, could you please raise the message-size limit ? I like to
> include patches in the mail body, so one can comment on it, but this
> one (and usually all patches I happen to make :) is much larger
> than 40k...

I usually find that diff -c produces the most readable output.  I bet
it wouldnt be as long either, but I could be wrong.

Ya, shawn, the message size should be at least large enough to include
uuencoded versions of the full source :)
 
I have committed changes since you made your changes.  Things might break.