[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RP] A big set of changes [patch included]
From: |
Gergely Nagy |
Subject: |
Re: [RP] A big set of changes [patch included] |
Date: |
Thu, 15 Feb 2001 19:26:59 +0100 |
User-agent: |
Mutt/1.3.12i |
Thus spoke Ryan Yeske <address@hidden> on 2001-02-15 10:12:49:
>
> 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.
>
That would have been too hard for me :)
> > 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? :)
In handler(), a call to XGetErrorText, which expects a preallocated string.
However, I guess this doesn't matter too much.
>
> > 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?
>
Both I think. FIrst of all, I prefixed everything with _RATPOISON, to avoid
clashes (this should not happen, but better safe than sorry).
The #define FOO 1 is something that makes it clear that it is defined. A
simple #define FOO does not stand out that much.
> > 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.
>
/me likes -u
> Ya, shawn, the message size should be at least large enough to include
> uuencoded versions of the full source :)
>
Agreed. ;)
> I have committed changes since you made your changes. Things might break.
>
I'm currently porting my changes...
> >From you patch, I gather that you made a copy of the tree, worked in
> that and diffed against the snapshot. Is this true? Can you not
> simply work in the cvs tree and before you post your patch, do another
> cvs update to resolve any conflicts? You can then also use cvs diff
> to generate your patch.
I was offline while working. So couldn't do that, however, I'm online now,
so I'll do that.
Erm.... Please don't commit anything before we decide what to do
about my patch. I won't be happy if I had to port it again.
BTW, I commited a patch to getopt.c that fixes a warning on FreeBSD.
I will now proceed with the manpage move and info updates. Basically,
I'll commit everything in my patch, except the src/ ones. Any objections ?
Thanks,
Gergely Nagy \ mhp/|8]
--
------------------------=]| address@hidden |[=------------------------
..................... Powered by bread 'n water .....................
pgpAz5qcxFPUL.pgp
Description: PGP signature