History Up key

History Up key

[Zvi Har'El]

Hi,

I have been using zsh-3.0.8 until yesterday, when I decided to switch to
zsh-4.0.1-pre2. I have one problem, which I want to report. It might be an old
story, but I am not aware of it:

I am using vi key binding. When I want to repeare my repeat command, I used
to hit the "cursor-up" key, see the last command and hit enter. The fact that I
am at vi-insert-mode still allowed the binding of "cursor-up" to
"up-line-or-history". 

However, upgrading to zsh 4, the binding apparently disappeared, and I have to
hit the escape key before the cursor-up to go into vi-command-mode. I think
this behavior is the same as in bash, but I find it a little annoying. Is this
intentional? Is there any setting I can  do to have the old behavior?

Thanks,

Zvi.


-- 
Dr. Zvi Har'El     mailto:rl@math.technion.ac.il     Department of Mathematics
tel:+972-54-227607                   Technion - Israel Institute of Technology
fax:+972-4-8324654 http://www.math.technion.ac.il/~rl/     Haifa 32000, ISRAEL
"If you can't say somethin' nice, don't say nothin' at all." -- Thumper (1942)
                                  Sunday, 16 Adar 5761, 11 March 2001, 10:58AM

RE: History Up key

[Andrej Borsenkow]

Hi,
>
> I have been using zsh-3.0.8 until yesterday, when I decided to switch to
> zsh-4.0.1-pre2. I have one problem, which I want to report. It
> might be an old
> story, but I am not aware of it:
>
> I am using vi key binding. When I want to repeare my repeat command, I used
> to hit the "cursor-up" key, see the last command and hit enter. The
> fact that I
> am at vi-insert-mode still allowed the binding of "cursor-up" to
> "up-line-or-history".
>
> However, upgrading to zsh 4, the binding apparently disappeared,
> and I have to
> hit the escape key before the cursor-up to go into vi-command-mode. I think
> this behavior is the same as in bash, but I find it a little
> annoying. Is this
> intentional? Is there any setting I can  do to have the old behavior?
>

bindkey -M viins $terminfo[kcuu1] up-line-or-history

replace $terminfo[kcuu1] with your favorite cursor-up esc sequence; I was lazy
to look it up. Actually, the above is quite portable (better is probably
${terminfo[kcuu1]-some fallback}, but I'm not sure if it really works).

I believe, change was deliberate, but I forgot the reasons ... it was really
long time - I think over three years. And I switched over to emacs binding
long ago (but have been using something similar before).

Anyway, in vi mode (bindkey -v) you have two keymaps - viins (for input) and
vicmd (for command mode). To change key binding use 'bindkey -M <keymap>'

-andrej

Re: History Up key

[Nadav Har'El]

On Sun, Mar 11, 2001, Andrej Borsenkow wrote about "RE: History Up key":
> > I am using vi key binding. When I want to repeare my repeat command, I used
> > to hit the "cursor-up" key, see the last command and hit enter. The
> > fact that I
> > am at vi-insert-mode still allowed the binding of "cursor-up" to
> > "up-line-or-history".
> >
> > However, upgrading to zsh 4, the binding apparently disappeared,
> 
> bindkey -M viins $terminfo[kcuu1] up-line-or-history
>..
> I believe, change was deliberate, but I forgot the reasons ... it was really
> long time - I think over three years. And I switched over to emacs binding
> long ago (but have been using something similar before).

I was also bit by this change. I've been using zsh for about 7 years now,
and this hasn't been changed 3 years ago - at least not in the 3.0.8 version
that is distributed with current Linux versions and which I've been using
lately (perhaps it was changed in the 3.1.* betas - I don't know).
In zsh 3.0.8 I have installed on my Redhat 7 machine, I get
$ bindkey
...
"^[[A"  up-line-or-history
...

[note that the above "bindkey" command showed the main keymap, which was
 vi insert mode because I had a "bindkey -v" or set VISUAL in my .zshrc or
 .zprofile]

Anyway, I wonder what actually happens in the current version (4.0.1-pre-2) -
when I type a few characters after the prompt and then change my mind, and
press an up-arrow, it used to move me to the previous line (similar to to
the effect of ESC-k-a, in vi mode - in very old versions I seem to remember
it was more like ESC-k, without the a). Now it seamingly does nothing, but
actually does something that prevents me from backspacing over the last
characters I typed (this has the effect similar to ESC-a in vi mode, i.e.,
go to command mode and then return to insert mode).  I think I understand
why the unbound up-arrow behaves as strangely as it does: The up-arrow is
(at least on my "screen" pseudo-terminal) simply ^[[A (ESC-[-A), which goes
to command mode, does nothing (or whatever '[' does) and then returns to
insert mode at the end of the line.
I see absolutely no reason why anybody would find this new behavior useful -
perhaps someone can enlighten me?

Anyway, if the new behavior isn't useful, and the previous one is (or at
least useful for backward-compatibility's sake), then maybe the above mapping
for insert-mode should be returned to be the default?


> Anyway, in vi mode (bindkey -v) you have two keymaps - viins (for input) and
> vicmd (for command mode). To change key binding use 'bindkey -M <keymap>'

Oh, I see the bindkey syntax and semantics changed considerably since the
3.0.* versions... Previously you had two unnamed maps: the "main map" (used
for vi insert mode) and "alternate map" (used for vi command mode).

Thanks,
	Nadav.

-- 
Nadav Har'El                        |        Sunday, Mar 11 2001, 16 Adar 5761
nyh@math.technion.ac.il             |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |Computers are like air conditioners.
http://nadav.harel.org.il           |Both stop working if you open windows.

Re: History Up key

[Nadav Har'El]

On Sun, Mar 11, 2001, Andrej Borsenkow wrote about "RE: History Up key":
> Hi,
> > I am using vi key binding. When I want to repeare my repeat command, I used
> > to hit the "cursor-up" key, see the last command and hit enter. The
> > fact that I
> > am at vi-insert-mode still allowed the binding of "cursor-up" to
> > "up-line-or-history".
> >
> > However, upgrading to zsh 4, the binding apparently disappeared,
> > and I have to

Of course, not only the cursor-up binding is missing from vi insert mode
in zsh 4 - the rest of the cursor bindings also seem to be missing.

Zsh 3.0.8 had:
$ bindkey
...
"^[[A"  up-line-or-history
"^[[B"  down-line-or-history
"^[[C"  forward-char
"^[[D"  backward-char
...

-- 
Nadav Har'El                        |        Sunday, Mar 11 2001, 16 Adar 5761
nyh@math.technion.ac.il             |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |If at first you don't succeed, skydiving
http://nadav.harel.org.il           |is not for you.

RE: History Up key

[Andrej Borsenkow]

> I was also bit by this change. I've been using zsh for about 7 years now,
> and this hasn't been changed 3 years ago - at least not in the 3.0.8 version
> that is distributed with current Linux versions and which I've been using
> lately (perhaps it was changed in the 3.1.* betas - I don't know).

Yes, it was changed in 3.1.x version. You may try to search archives
(<http://www.zsh.org/mla>). This was discussed on zsh-workers.

Zefram, any comment?

-andrej

PATCH: Re: History Up key

[Peter Stephenson]

> I am using vi key binding. When I want to repeare my repeat command, I used
> to hit the "cursor-up" key, see the last command and hit enter. The fact that
> I am at vi-insert-mode still allowed the binding of "cursor-up" to
> "up-line-or-history". 
> 
> However, upgrading to zsh 4, the binding apparently disappeared, and I
> have to hit the escape key before the cursor-up to go into
> vi-command-mode. I think this behavior is the same as in bash, but I find
> it a little annoying. Is this intentional? Is there any setting I can  do
> to have the old behavior?

This has been in the FAQ for some time (see below).  The change was made, I
think by Zefram, when the vi insert and vi command keymaps were made
properly separate keymaps: before that, if I remember rightly, only the
first key in the sequence was really distinct and prefix keys used a common
table.  So it was a side effect of the old implementation that it worked at
all.

But I can't for the life of me see why we shouldn't bind them by default in
vi insert mode.  The patch at the bottom does this.  Can anybody see why
this would be a problem?  (There's a timeout given by the parameter
$KEYTIMEOUT after which an escape is no longer treated as a prefix key and
switches to command mode, so you might notice a slight extra delay doing
that.)


  o  In vi insert mode, the cursor keys no longer work.  The following
     will bind them:

       bindkey -M viins '^[[D' vi-backward-char '^[[C' vi-forward-char \ 
                      '^[[A' up-line-or-history '^[[B' down-line-or-history

     (unless your terminal requires `^[O' instead of `^[[').  The
     rationale is that the insert mode and command mode keymaps for
     keys with prefixes are now separate.

Index: Src/Zle/zle_keymap.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/zle_keymap.c,v
retrieving revision 1.3
diff -u -r1.3 zle_keymap.c
--- Src/Zle/zle_keymap.c	2000/12/18 02:14:57	1.3
+++ Src/Zle/zle_keymap.c	2001/03/12 10:32:37
@@ -1023,6 +1023,7 @@
     Keymap emap = newkeymap(NULL, "emacs");
     Keymap amap = newkeymap(NULL, "vicmd");
     Keymap smap = newkeymap(NULL, ".safe");
+    Keymap vimaps[2], kptr;
     char buf[3], *ed;
     int i;
 
@@ -1066,15 +1067,20 @@
     /* vt100 arrow keys are bound by default, for historical reasons. *
      * Both standard and keypad modes are supported.                  */
 
-    /* vi command mode: arrow keys */
-    bindkey(amap, "\33[A",  refthingy(t_uplineorhistory), NULL);
-    bindkey(amap, "\33[B",  refthingy(t_downlineorhistory), NULL);
-    bindkey(amap, "\33[C",  refthingy(t_viforwardchar), NULL);
-    bindkey(amap, "\33[D",  refthingy(t_vibackwardchar), NULL);
-    bindkey(amap, "\33OA",  refthingy(t_uplineorhistory), NULL);
-    bindkey(amap, "\33OB",  refthingy(t_downlineorhistory), NULL);
-    bindkey(amap, "\33OC",  refthingy(t_viforwardchar), NULL);
-    bindkey(amap, "\33OD",  refthingy(t_vibackwardchar), NULL);
+    vimaps[0] = vmap;
+    vimaps[1] = amap;
+    for (i = 0; i < 2; i++) {
+	kptr = vimaps[i];
+	/* vi command and insert modes: arrow keys */
+	bindkey(kptr, "\33[A",  refthingy(t_uplineorhistory), NULL);
+	bindkey(kptr, "\33[B",  refthingy(t_downlineorhistory), NULL);
+	bindkey(kptr, "\33[C",  refthingy(t_viforwardchar), NULL);
+	bindkey(kptr, "\33[D",  refthingy(t_vibackwardchar), NULL);
+	bindkey(kptr, "\33OA",  refthingy(t_uplineorhistory), NULL);
+	bindkey(kptr, "\33OB",  refthingy(t_downlineorhistory), NULL);
+	bindkey(kptr, "\33OC",  refthingy(t_viforwardchar), NULL);
+	bindkey(kptr, "\33OD",  refthingy(t_vibackwardchar), NULL);
+    }
 
     /* emacs mode: arrow keys */
     bindkey(emap, "\33[A",  refthingy(t_uplineorhistory), NULL);
Index: Doc/Zsh/zle.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/zle.yo,v
retrieving revision 1.9
diff -u -r1.9 zle.yo
--- Doc/Zsh/zle.yo	2000/09/20 06:58:54	1.9
+++ Doc/Zsh/zle.yo	2001/03/12 10:32:37
@@ -222,7 +222,7 @@
 Move backward one character.
 )
 tindex(vi-backward-char)
-item(tt(vi-backward-char) (unbound) (^H h ^?) (unbound))(
+item(tt(vi-backward-char) (unbound) (^H h ^?) (ESC-[D))(
 Move backward one character, without changing lines.
 )
 tindex(backward-word)
@@ -273,7 +273,7 @@
 Move forward one character.
 )
 tindex(vi-forward-char)
-item(tt(vi-forward-char) (unbound) (space l) (unbound))(
+item(tt(vi-forward-char) (unbound) (space l) (ESC-[C))(
 Move forward one character.
 )
 tindex(vi-find-next-char)
@@ -357,7 +357,7 @@
 Move to the first event in the history list.
 )
 tindex(down-line-or-history)
-item(tt(down-line-or-history) (^N ESC-[B) (j) (unbound))(
+item(tt(down-line-or-history) (^N ESC-[B) (j) (ESC-[B))(
 Move down a line in the buffer, or if already at the bottom line,
 move to the next event in the history list.
 )
@@ -546,7 +546,7 @@
 Repeat the last vi history search, but in reverse.
 )
 tindex(up-line-or-history)
-item(tt(up-line-or-history) (^P ESC-[A) (k) (unbound))(
+item(tt(up-line-or-history) (^P ESC-[A) (k) (ESC-[A))(
 Move up a line in the buffer, or if already at the top line,
 move to the previous event in the history list.
 )

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

RE: PATCH: Re: History Up key

[Andrej Borsenkow]

>
> But I can't for the life of me see why we shouldn't bind them by default in
> vi insert mode.  The patch at the bottom does this.  Can anybody see why
> this would be a problem?

It's not worse than it was in 3.0.x - but why not use termcap/terminfo to find
esc for arrow keys? After all, not everybody is using vt100 (but I admit, that
real terminals now-a-days are probably something very exotic). It will make
these default bindings more useful.

-andrej

Re: History Up key

[Zefram]

Andrej Borsenkow wrote:
>I believe, change was deliberate, but I forgot the reasons ... it was really
>long time - I think over three years.

It changed early in the 3.1 series.  It was part of the overhaul of the
key binding system.  Until 3.0, the vi insert and command mode keymaps
were only separate for single-character bindings; multi-character
bindings were shared.  Actually, multi-character bindings were broken,
because they were tied into the single-character keybinding tables in
a messy way and the bindkey code didn't take account of the multiple
tables when updating them.

I was a little disappointed, at the time, at the conservative decision
not to retrofit the new keymaps into 3.0, thus leaving stable-version
users with a broken mechanism for all this time.  Of course, the people
most likely to be inventing new multi-character bindings are Emacs-mode
users, and they don't have a problem because they only use the one keymap.
Indeed, I don't recall us ever receiving a bug report relating to the
multi-character keybinding mechanism.

The separation of keymaps for multi-character keybindings brought up,
for the first time, the question of how arrow keys should behave in vi
insert mode.  For a combination of reasons, which I shall outline here,
I decided that arrow keys should not be treated specially, and that is
the behaviour of zsh prior to this week's proposed patches.

My decision to not treat arrow keys specially was influenced by two
classes of issue: firstly utility, and secondly correctness of emulation.
The correctness of emulation issue was simply that my policy has been
that zsh's vi mode should emulate vi as closely as feasible, and, as
I'm a vi purist, that means the historical vi.  (Although I'd be open
to changing the undo/redo semantics to match nvi's behaviour; anyone
fancy writing nvi-undo-change and nvi-repeat-change?)

Moving around during an insertion is, of course, a meaningless idea
in vi; every vi clone that does it actually does a horrible kludge.
ZLE's architecture is such that it's more sensible -- it's the structure
of vi insertions that is done in a kludgy way -- but accurate cloning
still suggests that vi mode should stick to what's sensible in vi.

The utility issue is essentially the result of all the trouble I've
had with vi clones that try to handle arrow keys during insertion.
There are three main problems:

1.  On many terminals, arrow keys aren't proper keys -- they send a
    sequence of characters starting with <esc>.  The problem is that <esc>
    *is* a proper key, and it's a valid thing to type during insertion --
    it delimits the end of the insertion.  This means that, for example,
    on the terminal I'm using now, vi and zsh (and any other program)
    can't tell the difference between me typing <up-arrow> and me typing
    <esc>OA (or <esc>[A depending on context, but that's another story).
    When I'm inserting, <esc>OA is a perfectly meaningful thing to type.
    So there's ambiguity, and attempts to reconstruct the original intent
    (which keys I pressed) sometimes go wrong.

1a. Incidentally, one of the main (flawed) techniques used to try to
    determine whether an arrow key is actually being pressed is to pause
    after reading <esc> and only interpret <esc>OA (or whatever) as an
    arrow key if the characters come quickly enough.  I find the pause
    when I'm typing <esc> annoying.

2.  On some terminals, arrow keys don't send escape sequences, but instead
    send single control characters.  For example, my favourite type of
    glass tty, the ADM3e, send ^H for <left-arrow>, ^J for <down-arrow>,
    ^K for <up-arrow> and ^L for <right-arrow>.  This kind of aliasing
    isn't a problem for <esc> -- that alias is well-established so
    everything knows to treat ^[ as <esc>.  But anything that tries to
    handle arrow keys on this kind of terminal ends up breaking various
    control characters (unless there's no way you'd want to use those
    control characters at the time).  Particularly problematic is that
    <left-arrow> often ends up being aliased with <backspace>.

3.  Another problem with programs that adapt to the key sequences that
    terminfo reports is that it becomes difficult to programmatically
    turn off the automatic key bindings for arrow keys, which I usually
    want to do where possible because of the problems already noted.
    It's difficult to remove a key binding that isn't always on the
    same keys.

All of this suggests that:

A.  It would be a bad idea to have arrow keys bound by default in vi
    insert mode.  Emacs mode and vi command mode don't have the same
    problems, because <esc> itself isn't bound to anything in those
    keymaps.

B.  Adapting the arrow key sequences to the local terminal is problematic.
    Binding things like ^H as arrow key sequences will cause big problems,
    so at minimum terminals where arrow keys don't send escape sequences
    should be treated as having no arrow keys.  With that heuristic in
    place, the only problem with adaption is the issue of programmatically
    knowing where those bindings are.

C.  The documentation should contain advice on how to turn *on* key
    bindings for arrow keys in vi insert mode.  This avoids the issue
    of difficulty in turning off the bindings.

-zefram