Re: Vi insert-mode cursor key bindings.

[Bart Schaefer <schaefer@xxxxxxx>]

On Nov 26, 12:53pm, Zefram wrote:
> Subject: Re: Vi insert-mode cursor key bindings.
> >These last two statements seem to contradict the first.  If an ESC-prefix
> >will interfere with the command "ESC", then how then does it "work
> >as expected"?  Or if it "works as expected", how does it interfere?
> 
> The cursor keys will then work, but if you press <ESC> there will be a
> delay, while zsh waits for the rest of an escape sequence, before
> vi-cmd-mode gets executed.  I am of the opinion that key-generated
> escape sequences are a bad idea in general, for this reason.

That's only bad if striking another key while zsh is waiting causes the
wrong thing to happen.

For example, if ESC is a prefix but ESC k is not bound to anything, and
I rapidly type ESC k, does zsh drop into vi-cmd-mode and move up a line?
Or does it feep because it has interpreted ESC k as a sequence?

I use the "evi" Emacs vi emulator [*] quite a bit; it had this problem
for quite a while.

> One better: I don't use cursor keys at all.  Their behaviour is too
> inconsistent to rely on them.  (The terminals that I regularly use
> don't generate ANSI escape sequences, so they wouldn't work in ZLE.)

But they do generate some kind of escape sequence, right?

If we're going to add default bindings for the cursor keys, we should
do it right -- we should read the term{cap,info} database and add the
binding for what it says the arrow keys generate, not just hardwire to
the vt100/ANSI sequences.  (Most vi that I've used actually map both
the ANSI and terminfo arrow keys, though not in insert mode.)

A further comment:  The reason for binding cursor keys in insert mode
in vi is typically *not* so that the user can navigate without leaving
insert mode (though I can't speak for nvi's reasons).  The reason is
best illustrated by considering what happens if you're navigating in
command mode on a slow or unreliable link.  You're holding down the
cursor key to scroll up or down the page, generating a stream of bytes
ESC O A ESC O A ESC O A ESC O A ESC O A ESC O A ESC O A ESC O A ....
On a slow line, you can generate around 100 key-presses of typeahead
pretty easily.  Now think about what happens when the line drops just
one of those ESC characters.

> >If I can bind them manually - without messing up "esc" on it's own -
> >then I'm content.
> 
> you *can* bind them manually if you want them, so I think we should
> default to the better vi emulation.

I agree with Zefram about vi-insert-mode, but I do think we should add
the terminfo-obtained bindings anywhere that zsh already has the ANSI
bindings.  That doesn't always work either, but at least we'll get it
right a bit more often.

[*] Evi is a more faithful emulation of vi than either vip or viper, in
spite of a couple small bugs.  I'm annoyed by the way vip and viper try
to "improve" on vi by e.g. redefining the way region movements work; a
lot of my editing habits rely on the "inferior" vi behaviors, and if I
wanted to change my editing habits I wouldn't be using a vi emulator in
the first place.

To answer the other obvious question:  I need emacs for GNATS access and
ediff-revisions.