Bug#305849: xterm: Xterm sends broken Ctrl-Left/Right/Up/Down sequences
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.
> 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.
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...
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....
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..?
> 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.
> 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..? :)
> 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.
--
Paul Evans
Global Services, Zeus Technology
http://www.zeus.com
Switchboard: 01223 525000
------
As switches have evolved into load balancers, and layer 4 load balancers
have evolved into layer 7 load balancers, what's the next step?
Find out by downloading the latest FREE white paper from Zeus at
http://www.zeus.com/go/gtme
Reply to: