On Fri, Apr 22, 2005 at 06:53:20PM +0100, Paul Evans wrote: > On Fri, 22 Apr 2005 13:29:35 -0400 > Thomas Dickey <dickey@radix.net> wrote: > > > Reverting xterm's configuration to the old behavior wouldn't be a bug fix. > > The reason for changing was one of the emacs people pointed out why the > > original encoding was not a good idea. (We're talking about a change to > > xterm from August 2002, btw). > > Yes... I've been reading the information online about the problem. I > see why the new behaviour is desirable... but I'm wondering if it > justifies modifying the default behaviour which makes everything else > break. From what I know, there are only a handful of applications that use the feature. > > I haven't looked to see where vim's storing this information. > > Oddly, terminfo only defines two of the four shifted arrow keys. > > Otherwise I would have added it there (and vim would then be expected > > to obtain it there). > > Yes, I have been looking in the terminfo details, and it is indeed > missing. > > Maybe what's required is an update to terminfo itself; code-wise, to > enable it to deal with all these settings. Are you aware of any such > project around that would encompass that? The idea of terminfo seems > sensible enough; keep a database of sequence => logic key mappings, and > use a standard library to access it. no (I maintain ncurses as well as xterm). ncurses' terminfo can define extra data (i.e., not defined by X/Open), but I use that feature sparingly. Even if I were to add it to xterm's terminfo, that wouldn't help the gnome-terminal (which has had more serious bugs against its xterm compatibility for more than a year). > Maybe if there's no real input from anywhere else, I might take a look > at expanding libterminfo, so it could use a new database storing this > extra info, and provide extra functions to be able to translate the > keys properly. This would be done in a careful way so as not to break > existing apps if the new library is installed, then one at a time, fix > the apps to use the new library instead. > > New behaviour would be to report the pair (base key, modifier); in a > similar way to the XKeyEvents; so e.g. vim would automatically know > it's a Control-Left, or a Shift-Meta-Home, or whatever... ugh - that would be a lot of work (and would be never completed) > It strikes me; if terminfo doesn't currently store these extra > sequences, does Vim et al. have a hard-coded string internally to > recognise it? How oddly broken.... vim has some tables to fill in for missing/incomplete termcap entries. > I make no mistake about it; I know just how massive a change this would > be; updating the code that implements the key-reading part of _every_ > console app in existence. But what I propose will be forward- > compatible. By the magic of dynamic libraries, existing binaries will > work with the new library; existing code will compile against a new > library, and existing behaviour will be unchanged. Simply, new > functionality will be added. > > Does that sound like a workable solution..? It's not (should not be) a change to the code, but to the data stored in initialization files. > > > Most of the comments have been from people who have the literal > > strings in their bash .inputrc file (the same for normal/application > > mode keys). > > Yeah, I have been pondering that. I can fix vim and readline this way.. > but what about irssi, .... The only proper solution is to fix > libterminfo. irissi needs a lot of work (its problems with terminfo are relatively minor). So I'd rather not bring it into the discussion. > > As I recall it, there are two parts of the change - perhaps readline > > is tripping over one of them (in its own changes): > > > > a) the control sequence beginning could be "ESC [" (CSI) or "ESC O" > > (SS3) > > Yes; I'm noticing an odd tendency to use one or the other.. Aren't > standards wonderful..? :) One's the normal, and the other the application cursor key initial part. > > b) the parameter could be first, e.g,. \E[2A, or after a dummy > > parameter (to avoid confusing applications that use it as a > > repeat count), e.g., \E[1;2A > > > > Since bash is using literal strings, while vim is actually parsing the > > escape sequences, it's also possible that vim's just doing the right > > thing (as well as it can, given no information). > > Yes; see above re: terminfo. But if it's not in an externally-editable file (and compiled in), that's not a good solution. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net
Attachment:
pgp8y9NJlcaPO.pgp
Description: PGP signature