[gpm] Some comments about the commits

[Nico Schottelius]

[gpm-list: This mail contains a off-list discussion, thus
 continaing a full quote so the context is clear]

Hello Jonathan,

Jonathan Nieder [Fri, May 30, 2008 at 02:20:26AM -0500]:
> > I would like to move our discussion to the maillinglist, so other can
> > participate, too.
> 
> Makes sense. CCing gpm. Context for those listening: I put up some
> patches (some from Debian, others to make libgpm quieter about the
> lack of gpmctl) at
> 
>     http://home.uchicago.edu/~jrnieder/gpm.git for-nico
> 
> and Nico kindly offered to review them.

And cc-ing did not work, because I configured mailman to drop posts
from non-subscribers :-)

> > I just release 1.20.4 and took some time to review the patches:
> >
> > c231a91 [Debian's 013_xterm_mouse_support_000 --jrn]:
> >    Afaik the Linux-konsole also has the kmous property. And thus
> >    breaks Linux on the console. Correct me, if I am wrong.
> 
> Agh - you are right.
> 
> The changelog to terminfo.src suggests "linux" has capability
> kmous because of Joerg Schoen's patch for gpm in
> patches/todo/xterm-mouse-for-console.patch.  Do you know if
> this patch is applied in any distros? (Just curious.)

Sorry, I don't know anything about that patch, but maybe someone
else on the list.

> "A hacker's guide to ncurses internals" and terminfo(5) imply
> that kmous is just a fake function key name --- it being set does
> not imply that the terminal has xterm-style mouse support, although
> it not being set probably implies the terminal is either old or
> does not support xterm-style mouse reporting. As a reliable way
> to check for a terminal with mouse reporting, kmous seems to be
> useless.

That's why it's named curses ;-)

> Using kmous as an indicator anyway, we find that screen, rxvt,
> Eterm, xterm, putty, konsole, kterm, gnome-terminal, and some
> other terminals besides support xterm-style mouse reporting.
> Checking TERM is just not going to detect them all.

That's true, using $TERM would result in a possible long and
almost always incomplete list.

Perhaps a better way to detect xterm-mouse-support is
via checking if $DISPLAY is set?

> One (short-term) solution would be to allow programs to specify
> that they want to use xterm-style mouse reporting. Maybe the
> program could indicate this by calling Gpm_Open with flag=-2
> or something - but that would break any legitimate programs
> using flag=-2 to mean "I want to register myself as a default
> handler". There is probably a better way. Anyway, afterwards,
> users could e.g. run "mev -x" to use mev from rxvt.
> 
> In the long term, I think it would make sense to have some
> terminfo capability representing "This terminal supports
> xterm-style mouse reporting" so that at least rxvt etc would
> work out of the box. But others have probably thought more
> about this than I have, so I won't say any more about that.

Perhaps we should contact the authors of urxvt, perhaps they have
some sane ideas.

In general, which way we will go - I would like to implement new style
xterm handling only in the gpm-2-* branches to not break things in gpm-1.

> A comment in bug #472063 suggests the use of del_curterm in the
> patch is not entirely safe - another reason not to apply it. Sorry
> about that. I will be more careful in the future.

No problem, you are doing a good job.

> > 429816e... [Make gpm recognize -V for backwards compatibility]:
> >    Why do you that is needed? Where does it help?
> 
> It was meant to cause old configuration files from version 1.19.6
> that use the -V[verbosity increment] option not to leave people
> stranded without a mouse (Debian bug #466522). But I made a mistake
> in forward-porting the patch, so it is bogus (I am missing a :: after
> the V in options[]) and I am very glad you didn't take the patch.
> 
> Being without a mouse for a short time is not really a tragedy.
> Arguably, the correct fix would be for the distributors' packaging
> scripts to appropriately update the configuration file for the
> initscript or notify the user. Backwards-compatibility shims like
> this are not necessary. It is up to you whether you think they
> are desirable.

I do not think backwards-compatibility is really needed, as it takes
only a few minutes to resolve that issue in the distribution.

> > c792c01...: applied
> > 6085fb3...: applied
> > 41bc0d2...: applied
> > bfc4bef...: applied
> 
> I just checked over these to make sure they are not insane after
> those two mistakes. They seem ok - thank you for applying them.
> 
> > Try to stay with short commits, it makes life very easy to pick only
> > parts and not to need to split the commits of again!
> 
> Thanks. You have been very helpful.
> 
> Sincerely,
> Jonathan

Have a good night,

Nico

-- 
Think about Free and Open Source Software (FOSS).
http://nico.schottelius.org/documentations/foss/the-term-foss/

PGP: BFE4 C736 ABE5 406F 8F42  F7CF B8BE F92A 9885 188C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.linux.it/pipermail/gpm/attachments/20080602/c73d307a/attachment.pgp