Re: Binding Home and End

[Frank Terbeck <ft@xxxxxxxxxxxxxxxxxxx>]

Peter Stephenson wrote:
> On Sat, 30 Jan 2010 12:25:15 +0100
> Frank Terbeck <ft@xxxxxxxxxxxxxxxxxxx> wrote:
>> Mikael Magnusson wrote:
[...]
>> > I imagine it would at least break lots of keybinds for people who don't use
>> > terminfo.
>>
>> Yes, of course. :)
>> I was rather getting at whether doing this was likely to break something
>> like menu-selection or something similar. I don't think it would, but
>> Peter's mention about "chaos" made me a little uneasy.
>
> Compatibility was really my only worry... congratulations if you've
> puzzled out terminal application cursor / keypad modes, but I suspect
> 99.something % of shell users just look at what sequences a key happens
> to be sending and bind their functions to that, so it wouldn't be a good
> idea to tinker with those now.

Absolutely. Actually changing the defaults would probably piss too many
people off. I just wanted to make sure doing this smkx/rmkx routine
wouldn't break anything.

I know, that at least Debian uses $terminfo to set up some special keys
in their global zshrc. They do do they s/^[O/^[[/ dance which covers a
number of cases. But that doesn't always work. Maybe they should
consider using the zle hooks you gave earlier.

> (Although it's certainly arguable, it's not completely clear that a
> shell's line editor is an "application" in the strict sense, the whole
> distinction being a not very happy historical accident in the first
> place.  The way shells evolved means that to begin with they were just
> using raw input; at some point they crossed the boundary to become
> something more sophisticated.  The simple application / raw distinction
> doesn't really fit.)

Does somebody on the list actually know why such a distinction was made
at all? And why it would make sense to have a key like `HOME' send
different bytes depending on which mode is active?

> If you're not relying on the particular O / [ key sequence you're
> getting at the moment, however, as far as I know the shell code I gave
> should work fine for you (obviously, do let us know if you find a
> problem).

Sending smkx when zle starts should make the values from $terminfo valid
within the line editor. So no rewriting O to [ should be necessary.

I've tested this with a number of terminals, with and without terminal
multiplexers (screen and tmux), and so far I have not seen any
breakages. (So far, only tried Linux, though.)

> This is probably worth mentioning in the FAQ.

Probably. FWIW, the code I'm using looks like this:

Terminfo:
if [[ -n ${terminfo[smkx]} ]] && [[ -n ${terminfo[rmkx]} ]]; then
  function zle-line-init () { echoti smkx }
  function zle-line-finish () { echoti rmkx }
  zle -N zle-line-init
  zle -N zle-line-finish
fi

Termcap (NetBSD doesn't have terminfo, AFAIK):
if [[ -n ${termcap[ks]} ]] && [[ -n ${termcap[ke]} ]]; then
  function zle-line-init () { echotc ks }
  function zle-line-finish () { echotc ke }
  zle -N zle-line-init
  zle -N zle-line-finish
fi

I only tested the termcap solution briefly.

Anyway, that's part of my keyboard setup now; if something blows up in
my face, I'll let you know. :-)

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925