Re: Pressing esc twice then left arrow deletes last character

[James Rowell]

On Wed, 2009-07-15 at 16:01 -0400, Chet Ramey wrote:
>
> This isn't really a bug.  It's caused by the extra ESC,
> which results in an unexpected keybinding being activated.
> I'm going to assume that, like mine, your left arrow key
> expands to ^[[D (ESC, left bracket, D).

For the sake of completeness I'm replying to this post with
a summary of a conversation that Chet and I had offline.  I
don't believe Chet finally agreed with me that this is
indeed a bug, but I'll make the case publicly for your
interest and for thoughts from others.  (He did say however
"If I can make this work with a small amount of effort, I
will; I'm not willing to spend a lot of time on a minor
problem." - while I disagree that it's a minor problem, I
greatly appreciate the effort.)

I understand bash's keymap functionality in readline is how
the arrow keys for vi-editing mode are implemented.  While
this might be a boon to the implementers of bash's command
line functionality, it conflicts with what *must* be a
fundamental design specification of how any vi-command mode
should behave.

In a nutshell - any implementation of "vi-command mode"
should have the behavior that pressing ESC for a second
time or repeatedly has no effect except perhaps to sound the
"bell".  The first ESC should take one to command mode, out
of insert mode, and any subsequent pressing of ESC (while
still in command mode) should be a NULL operation.  I quote
from "Learning the vi Editor" by Linda Lamb, O'Reilly &
Associates, Inc., August 1994, page 12.

    Sometimes you don't know whether you are in insert mode
    or command mode.  Whenever vi does not respond as you
    expect, press ESC once or twice to check what mode you
    are in.  When you hear the beep, you are in command
    mode.

vi users frequently hit the escape key.  It's something we
learn to do early on - when in doubt - hit the escape key.
You might be editing something - walk away from the computer
- come back - forgetting what your mode is, hit the escape
key, reenter text mode by typing "a" or whatever, or you are
just thinking - you loose track of what you were doing in
the editor - and so you hit escape again, before you
continue.  Sometimes you just hit escape twice fast, because
you have a nervous habit - whatever - it's how vi works,
it's totally harmless to hit escape over and over.  It's
important to respect this fundamental behavior of vi
and any implementation of vi that does not is in error.

Compare with csh's implementation of vi-mode, it works
correctly with the arrow keys and hitting ESC repeatedly has
no ill effect.

Another point I made to Chet was - please don't mix what I'm
asking for (fixing this bug) with technically why it's
difficult or not, or even possible with the current
implementation of readline.  The vi treatment of ESC is well
defined and simple.  If it's not simple to implement that
should not be an issue for the bash user to be concerned
about.  Perhaps it's just an option for vi-command-mode
users, to get the correct behavior and give up some other
readline functionality somewhere (hopefully not loosing the
arrow keys).

I'm not reporting this, or bringing this up to be a
stickler, I was encountering this problem frequently when I
migrated myself from csh to bash a while ago.  It took me a
while to figure out why I was loosing text at the end of my
line.  I googled for this problem and found other people who
were experiencing similar issues, but couldn't seem to pin
down the problem.  I think the issue with readline, keymaps
and the arrow keys explains all cases like this in bash.

Chet, or whoever, may or may not choose to fix this bug, but
if it's not fixed it should be recognized that it is in fact
a bug and it will affect how all vi-users interact with
bash.  Basically we will have to retrain ourselves to avoid
the arrow keys in case we've hit escape a couple times too
many.  I'm hoping it will be fixed in due course and am
greatly appreciative of everyone's efforts regardless of
what the outcome is.

Thanks,
James Rowell