Re: big key binding patch

[Zefram <zefram@xxxxxxxxxxxxxxxxx>]

>That'll teach me to put the rationale for such hacks into comments.
>Don't you appreciate patches sent in by wannabe hackers from all
>over the world?

Sure, but a rationale would indeed have helped here.

>Anyway, with Zefram's patch, which is sure impressive, I'm experi-
>encing core dumps in vi mode.  Let's say, I'm pressing those keys in
>an xterm: Cursor-up, cursor-down, cursor-up, ie.
>
>  ~/wrk/z/zsh-3.1.0-test3/Src> <ESC>[A<ESC>[B<ESC>[A
>  Program received signal SIGSEGV, Segmentation fault.
>  0x8098b2b in getkeycmd () at zle_main.c:542
>  542             if (cky->func == z_undefinedkey)
>  (gdb) [A
>        ^^
>Now, after two feep()s and the third key-press, the prefix is recog-
>nized, but there's no binding for it in keybindtab (== vikeybindtab),
>dereferencing cky (== NULL).

OK, I'll look into that.  <ESC> shouldn't be a prefix in vi insert
mode, but it is in vi command mode; the switching between modes in that
sequence of keys is probably responsible.

>                              The easy way out is to add the default
>cursor key bindings also to vi insert mode. 

Do not do that.  The cursor keys should *not* be bound in vi insert
mode, only in emacs mode and vi command mode.  We should fix the bug
that causes SEGV, not provide a broken workaround.

>[ In a similar vain, what exactly happens to meta-bindings like "\M-x"
>  after `bindkey -m'? They're displayed as "^[x", and `bindkey -{a,v}m'

In emacs mode the meta binding table is by default used to generate a
set of <ESC>x bindings.

>  makes them look like (*iso8859-1 alert*) "ø".  They're working OK,
>  albeit difficult to locate on my keyboard. ]

The behaviour hasn't changed.

-zefram