[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#305849: xterm: Xterm sends broken Ctrl-Left/Right/Up/Down sequences



On Fri, Apr 22, 2005 at 05:20:35PM +0100, Paul Evans wrote:
> On Fri, 22 Apr 2005 11:52:24 -0400
> Thomas Dickey <dickey@radix.net> wrote:
> 
> > "supposed to" sounds like a user configuration issue (in this case it is).
> 
> Well, I've not changed any local settings to do this. This is a
> standard stock install of debian, no customisations to xterm or vim.
> Many other people can confirm the same behaviour, both running debian,
> and other distributions (e.g. gentoo).
> 
> There may well be a configuration setting combination required to get
> this all working correctly; in which case my bug report becomes
> "standard install configuation is wrong". But either way, a bug
> persists. A default install does not behave as expected.

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).

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).

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).

> 
> > See xterm's manpage where it documents modifyCursorKeys.
> > 
> > (ignoring the misleading comment about Linux console, the
> > issue with gnome-terminal is that it copied xterm's behavior some
> > time ago and did not incorporate this particular fix).
> 
> Right. I've looked at that, and tried each of the values 0 to 3:
> 
> 0:		works in vim		fails in readline
> 1:		fails in vim		fails in readline
> 2(default):	fails in vim		fails in readline
> 3:		fails in vim		fails in readline
> 
> I.e. I cannot find any value that makes bash work. Each setting
> produces different output, yet none of them is correct.

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)

	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).

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net

Attachment: pgpUcg1q5mjGN.pgp
Description: PGP signature


Reply to: