[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
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ gpm mailing list gpm@xxxxxxxxxxxxxx http://lists.linux.it/listinfo/gpm