Re: History Up key

["Nadav Har'El" <nyh@xxxxxxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxx             |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |Computers are like air conditioners.
http://nadav.harel.org.il           |Both stop working if you open windows.