Vi insert-mode cursor key bindings.

Vi insert-mode cursor key bindings.

[Duncan Sinclair]

>>I'm curious.... why?
>
>Because vi doesn't bind them, and because <ESC> already has a meaning
>that its use as a prefix would interfere with.
>
>>                      And what happens if you bind them using bindkey?
>
>It'll work as expected.
>
>>Can we use other ESC-prefixed bindings in vi-insert mode?
>
>Yes, just bind them using bindkey.

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?

I can see a lot of e-mail to the list saying "the up-arrow key doesn't
work in vi mode".  I seem to recall the same happening before.


>Have you tried using this binding after you gave i a count?  Look at
>what that binding does; it's a disgusting kludge.

Agreed.  But then I'm hardly likely to be using the cursor keys during
count-prefixed inserts with vi.  (I don't use the cursor keys during
inserts in vi, in fact, in vi, I don't use the cursor keys at all.)

While I'm just as keen to see a good vi emulation from zle, we must
still realise that zsh is a shell, not an editor.  (In vi I don't
use the cursor keys - in zsh I use them all the time.)

There are lots of people out there that think that "up-arrow,return"
is a perfectly reasonable thing to want to do, without having to hit
"esc" first.  (myself included.)


If I can bind them manually - without messing up "esc" on it's own -
then I'm content.  But I think it'll be a problem for other people.


Cheers,



Duncan.

Re: Vi insert-mode cursor key bindings.

[Zefram]

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

>Agreed.  But then I'm hardly likely to be using the cursor keys during
>count-prefixed inserts with vi.  (I don't use the cursor keys during
>inserts in vi, in fact, in vi, I don't use the cursor keys at all.)

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

>While I'm just as keen to see a good vi emulation from zle, we must
>still realise that zsh is a shell, not an editor.  (In vi I don't
>use the cursor keys - in zsh I use them all the time.)

Yes.  There is a case to be made for binding the cursor keys, but ...

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

>                   But I think it'll be a problem for other people.

Only people that don't read the manual.

-zefram

Re: Vi insert-mode cursor key bindings.

[Bart Schaefer]

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.

Re: Vi insert-mode cursor key bindings.

[Zefram]

>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?

It does the right thing in that case.  But <ESC>[A is a likely
mistyping of some reasonable editing actions.  In any case, I find the
delay annoying: if I pressed <ESC>, it should take the action for <ESC>
immediately.  With no escape sequences around, this is acheivable.

>> 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?

No.  Actually, I usually use a couple of Lear Siegler ADM 3E
terminals.  These generate ^H for left, ^J for down, ^K for up[1] and
^L for right.  Some programs can handle this (vi for one), but many get
confused.

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

Yes, we should.  But we should watch out for weird terminals like mine,
and be careful not to squash anything otherwise bound.  Personally I
would miss using right arrow to clear the screen, if it were to be
rebound.

-zefram

[1] We keep getting inexperienced first year undergrads trying to edit
their Pascal assignments in Jove on these terminals, and deleting half
their program while trying to navigate.  I love these terminals.  (-:

Re: Vi insert-mode cursor key bindings.

[Bart Schaefer]

On Nov 26,  6:09pm, Zefram wrote:
> Subject: Re: Vi insert-mode cursor key bindings.
> 
> >> 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?
> 
> No.  Actually, I usually use a couple of Lear Siegler ADM 3E
> terminals.  These generate ^H for left, ^J for down, ^K for up[1] and
> ^L for right.

Ah, yes, back at OGI we used to have some Qume terminals with this
bizarre behavior.

> Personally I
> would miss using right arrow to clear the screen, if it were to be
> rebound.

Chuckle.

I agree that zsh should be intelligent about this sort of thing.

Re: Vi insert-mode cursor key bindings.

[Duncan Sinclair]

Zefram writes:
>It does the right thing in that case.  But <ESC>[A is a likely
>mistyping of some reasonable editing actions.  In any case, I find the
>delay annoying: if I pressed <ESC>, it should take the action for <ESC>
>immediately.  With no escape sequences around, this is acheivable.

How long is the delay?  One second is probably too long.  Maybe 200ms
would be OK.  I don't know how long a delay nvi uses but it does seem
a little too long.  Of course, the delay should be set according to
the value of "BAUD".  (Though baud rates are rarely important these days...)

>No.  Actually, I usually use a couple of Lear Siegler ADM 3E
>terminals.  These generate ^H for left, ^J for down, ^K for up[1] and
>^L for right.  Some programs can handle this (vi for one), but many get
>confused.

I occasionally use an ADM 5A, with the same behaviour.  Maybe it's
just me, but I always thought this set to be a fairly obvious choice.

>>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.)
>
>Yes, we should.  But we should watch out for weird terminals like mine,
>and be careful not to squash anything otherwise bound.  Personally I
>would miss using right arrow to clear the screen, if it were to be
>rebound.

That's true.

Another thing to watch for is termcap initialisation and the difference
between "<ESC>[A" and "<ESC>OA".

>From the xterm termcap entry:

        ku=\EOA:
	kd=\EOB:
	kr=\EOC:
	kl=\EOD:

But the zsh bindings are:

	"^[[A"  up-line-or-history
	"^[[B"  down-line-or-history
	"^[[C"  forward-char
	"^[[D"  backward-char

These are different because the termcap database is only correct after
the "ti" string has been sent - "ti" is the "string to begin programs
that use termcap".  It has a partner - "te".

So, shouldn't we be using "ti"?  No.  Because on an xterm the "ti"
string does this:

     In VT102 mode, there are escape sequences  to  activate  and
     deactivate  an  alternate  screen  buffer, which is the same
     size as the display area of the window.  When activated, the
     current  screen  is  saved  and  replaced with the alternate
     screen.  Saving of lines scrolled off the top of the  window
     is  disabled  until  the  normal  screen  is  restored.  The
     termcap(5) entry for xterm allows the visual editor vi(1) to
     switch  to  the  alternate screen for editing and to restore
     the screen on exit.
		- xterm man page

I don't think this is what is wanted for an interactive shell.

But then someday you'll find a terminal that won't play unless you
send the "ti" string.

Any thoughts on this?  (Apart from lynching Bill Joy for giving us all
this nonsense.)

Cheers,


Duncan.