Bind Ctrl+Left to backward-word (and Ctrl+Right to forward-word)

[kernc]

Binds some additional sequences to (emacs-)backward-word and forward-word. The problem is that terminfo doesn't know about Ctrl+ArrowKeys, so one has to resort to using raw sequences. The sequences were copied from Debian's /etc/inputrc (readline configuration), so it should be fairly portable. It works in xterm and rxvt terminals, it doesn't work on TERM=linux (virtual console) as Ctrl+Arrows send the same sequence as Arrows alone.

http://zshwiki.org/home/zle/bindkeys
http://sources.debian.net/src/readline6/6.2+dfsg-0.1/debian/inputrc?hl=44#L44

[sorin-ionescu]

Can't the terminfo database be fixed instead? Databases can be installed in the home directory.

[kernc]

Can't the terminfo database be fixed instead?

I am absolutely not in position to suggest such corrections. The current terminfo upstream is aware of the issue, this is what they have to say, and I hardly understand much of it.

Yet Debian, serving hundreds of thousands of users, sets this in their /etc/inputrc, which is the default readline configuration file, which is the default readline library for bash (et al. REPL shells), which is the default user shell by default. And it works out of the box — presto! :)

[sorin-ionescu]

Could you paste /etc/inputrc please?

[sorin-ionescu]

I would rather have you define those in the $key_info array; so, they are reusable.

[kernc]

What identification keys do you recommend? C-Left/1 / CLeft1 / C-Left/xterm ... ?

[sorin-ionescu]

ControlLeft and ControlRight?

[kernc]

I linked to the inputrc in the commit message. This is the template /etc/inputrc, if previously non-existant, gets created from. It is present in readline-common package.

[sorin-ionescu]

Is anything else broken?

[kernc]

Here, nice and squashed. Whether anything else is broken — I don't know. I'm not a proficient terminal user so I don't use all the exotic keybindings (obviously, since I propose Ctrl+Arrows from the GUI editors even though Alt+Arrows or Alt+B/F are normally available). I know I would appreciate Ctrl+Home jumping directly to start of command (in a multiline command, particularly), and Ctrl+End to the end, but the terminals I tried all assign the same sequence to Ctrl+Home as to Home alone, so tough luck there.

[sorin-ionescu]

You'll have to detect the operating system using $OSTYPE and set ControlLeft to the proper sequence.

[kernc]

And what sequence am I supposed to use with regard to specific $OSTYPE? The sequences, as I understand, are bound to a particular terminal emulator, not necessarily OS. What I can do is apply \eOc and \eOd conditionally only if $TERM=*rxvt*, like Debian does. The other codes apply for xterm, it seems, and anything else is beyond my understanding.

[sorin-ionescu]

I am sorry. I meant, check $TERM, not $OSTYPE.

[kernc]

So, like Debian does it, apply \e[1;5D \e[5D \e\e[D unconditionally and \eOd only if $TERM = *rxvt* ? Or all of the former only when $TERM != *rxvt*? I'd hate to decide myself.

[sorin-ionescu]

You'd need to figure out for which terminals Debian is mapping each one, detect the terminal, then append to the array.

[kernc]

It now follows the Debian bahavior. It applies the first three sequences unconditionally, and the last if term is a rxvt.

[sorin-ionescu]

Bind only one sequence, not three of them, because it makes the use of this array inconsistent. Find out $TERM for each then set key_info['ControlLeft']='foo'.

[kernc]

And how do you propose I do that? There are various accounts for correct xterm values — somebody here says their xterm works with ;5D, my xterm works with \e[1;5D if I let zsh parse my .zshrc and with ;5D if I run zsh --no-rcs.... I don't think these can be reliably inferred from $TERM, I though we were trusting Debian with this...

And what do you mean by inconsistent? Yes, it has several possible values, all of which apply, obviously.

[sorin-ionescu]

Does Konsole set $TERMINAL_PROGRAM?

[kernc]

Haven't tried konsole, but none of my other terminal programs sets it. Does this help?

[sorin-ionescu]

What I mean by inconsistent is that the array is expected to be used as $key_info[ControlLeft] not ${(s: :)key_info[ControlLeft]}.

[kernc]

Yeah, but there are three possible values. That's why I asked how I should name them. ControlLeft1, ControlLeft2, ControlLeft3 ? And how then do I conditionally add the rxvt ControlLeft4? And do I check for each one if it's set before applying bindkey to it?
What public-facing interface precisely are you maintaining backwards-compatibility with by enforcing this? I understand you don't want it all hacked together, but I don't think I can imagine an equally-elegant way of taming this better. So please advise. :-)

[sorin-ionescu]

I have no good answer.