Vimode problem (key press dropping)

Vimode problem (key press dropping)

[alx741]

ZSH users,

I'm using zsh Vimode for a while now, with a problem all the time:

When i hit ESC two times the next letter is ignored, so in order to 
enter insert mode i need to hit 'i'/'a' two times two. This is the same 
for any even number of ESC, the problem is the same for 4 hits but no 
for 3 times so i can say the second ESC hit leave the shell listening 
and it just drop the next key press.

I've already tried removing all my configuration and using a default 
config ZSH instance and then using 'bindkey -v' but the problem 
persists.

Am i doing something wrong?, thank you very much!

Greetings from Ecuador.

Re: Vimode problem (key press dropping)

[Oliver Kiddle]

alx741@riseup.net wrote:
> 
> When i hit ESC two times the next letter is ignored, so in order to 
> enter insert mode i need to hit 'i'/'a' two times two. This is the same 
> for any even number of ESC, the problem is the same for 4 hits but no 
> for 3 times so i can say the second ESC hit leave the shell listening 
> and it just drop the next key press.

The problem is that from vi command mode, the escape key is not bound to
anything. If you bind escape to do absolutely nothing, the problem goes
away.

  bindkey -as '\e' ''

Or alternatively, the following is what vim does:

  bindkey -a '\e' beep

Part of the reason behind the behaviour you see is that the cursor keys
typically are bound and when you press the cursor keys, what zsh sees is
an "escape sequence": a series of characters that start with an escape
character. This also means that after seeing an escape character, zsh
has to wait to see if more characters arrive. You might also want to
tweak the KEYTIMEOUT variable to reduce this delay.

Question to -workers subscribers: how should we address this in the
defaults? I also have escape bound to set REGION_ACTIVE=0 from the
visual keymap which should perhaps also be default behaviour (vim does
that). Note that escape being a prefix character is what causes the
subsequent 'i'/'a' to be ignored.

Oliver

Re: Vimode problem (key press dropping)

[Mikael Magnusson]

On Wed, Jul 29, 2015 at 11:26 AM, Oliver Kiddle <okiddle@yahoo.co.uk> wrote:
> alx741@riseup.net wrote:
>>
>> When i hit ESC two times the next letter is ignored, so in order to
>> enter insert mode i need to hit 'i'/'a' two times two. This is the same
>> for any even number of ESC, the problem is the same for 4 hits but no
>> for 3 times so i can say the second ESC hit leave the shell listening
>> and it just drop the next key press.
>
> The problem is that from vi command mode, the escape key is not bound to
> anything. If you bind escape to do absolutely nothing, the problem goes
> away.
>
>   bindkey -as '\e' ''
>
> Or alternatively, the following is what vim does:
>
>   bindkey -a '\e' beep
>
> Part of the reason behind the behaviour you see is that the cursor keys
> typically are bound and when you press the cursor keys, what zsh sees is
> an "escape sequence": a series of characters that start with an escape
> character. This also means that after seeing an escape character, zsh
> has to wait to see if more characters arrive. You might also want to
> tweak the KEYTIMEOUT variable to reduce this delay.
>
> Question to -workers subscribers: how should we address this in the
> defaults? I also have escape bound to set REGION_ACTIVE=0 from the
> visual keymap which should perhaps also be default behaviour (vim does
> that). Note that escape being a prefix character is what causes the
> subsequent 'i'/'a' to be ignored.
>
> Oliver

I always felt like how it should work if we get the string "abc", is
first abc is looked up and we find it isn't bound to anything, the a
gets treated as a separate input string, then we look up bc instead,
etc. What we do now is just discard the whole string as
"undefined-key".

-- 
Mikael Magnusson

Re: Vimode problem (key press dropping)

[Bart Schaefer]

On Jul 29,  2:35pm, Mikael Magnusson wrote:
}
} I always felt like how it should work if we get the string "abc", is
} first abc is looked up and we find it isn't bound to anything, the a
} gets treated as a separate input string, then we look up bc instead,
} etc.

The problem with that is that if you have an unbound function key on
your keyboard, striking it will cause unpredictable effects when the
leading ESC is ignored and the rest of the sequence begins to be
interpreted as individual characters.

} What we do now is just discard the whole string as "undefined-key".

Which is correct if the whole sequence came from a single keystroke;
the real difficulty is determining whether that happened.

Re: Vimode problem (key press dropping)

[Mikael Magnusson]

On Wed, Jul 29, 2015 at 5:30 PM, Bart Schaefer
<schaefer@brasslantern.com> wrote:
> On Jul 29,  2:35pm, Mikael Magnusson wrote:
> }
> } I always felt like how it should work if we get the string "abc", is
> } first abc is looked up and we find it isn't bound to anything, the a
> } gets treated as a separate input string, then we look up bc instead,
> } etc.
>
> The problem with that is that if you have an unbound function key on
> your keyboard, striking it will cause unpredictable effects when the
> leading ESC is ignored and the rest of the sequence begins to be
> interpreted as individual characters.
>
> } What we do now is just discard the whole string as "undefined-key".
>
> Which is correct if the whole sequence came from a single keystroke;
> the real difficulty is determining whether that happened.

Well, what almost always happens is we eat the ^[[1 part and insert
the ~ literally, which is confusing. If we literally inserted the
whole ^[[1~ string, it would be more obvious for a user what they had
to put in their keybind commands. "You can run cat and press the key
to see what it sends" "oh, okay".

-- 
Mikael Magnusson

Re: Vimode problem (key press dropping)

[Bart Schaefer]

On Jul 29,  5:35pm, Mikael Magnusson wrote:
}
} Well, what almost always happens is we eat the ^[[1 part and insert
} the ~ literally, which is confusing.  If we literally inserted the
} whole ^[[1~ string, it would be more obvious

But "literally insert the whole string" presumes either that you are
in the viins keymap to begin with, or that any unrecognized characters
kick you into viins even if you started in vicmd.  Also, treating a
leading ESC as a self-insert in viins is problematic.

Re: Vimode problem (key press dropping)

[Mikael Magnusson]

On Wed, Jul 29, 2015 at 5:51 PM, Bart Schaefer
<schaefer@brasslantern.com> wrote:
> On Jul 29,  5:35pm, Mikael Magnusson wrote:
> }
> } Well, what almost always happens is we eat the ^[[1 part and insert
> } the ~ literally, which is confusing.  If we literally inserted the
> } whole ^[[1~ string, it would be more obvious
>
> But "literally insert the whole string" presumes either that you are
> in the viins keymap to begin with, or that any unrecognized characters
> kick you into viins even if you started in vicmd.  Also, treating a
> leading ESC as a self-insert in viins is problematic.

I suppose in vicmd mode it would be problematic if the individual keys
were treated as commands, since 7~ will just toggle case 7 times. This
is what happens in vi though so... :). I was actually thinking about
emacs mode primarily when I wrote it though, I forgot what the thread
is about. And I didn't mean to say that unknown characters should be
self-inserted always, just treated on their own instead of eaten into
the undefined-key combo, but in emacs mode all the keys would most
likely be self-inserted. Anyway, I get the impression nobody else is
for this scheme.

-- 
Mikael Magnusson

Re: Vimode problem (key press dropping)

[Oliver Kiddle]

Mikael Magnusson wrote:
> Well, what almost always happens is we eat the ^[[1 part and insert
> the ~ literally, which is confusing. If we literally inserted the
> whole ^[[1~ string, it would be more obvious for a user what they had
> to put in their keybind commands. "You can run cat and press the key
> to see what it sends" "oh, okay".

With a default setup, that tends to happen because at some point the
sequence read so far is no longer recognised as a prefix. Once you've
bound a few keys, that's less likely.

We could alleviate this issue by binding a few more keys by default at
startup. Insert, Delete, Home, End, Page Up/Dn and the function keys
all have termcap entries. Is there really a good reason not to bind at
least the first four of these. What was the historical reason for not
doing so? Also, anyone know why the sequences for the cursors need to be
passed through tputs()?

overwrite-mode for insert and delete-char for delete is probably not
controversial. For home and end, it'd either be beginning-of-line and
end-of-line or the -buffer-or-history versions. Others don't have an
obvious binding.

I also wonder whether we should consider trying to do something for
Ctrl/Alt Left and Right to make it easier for new users.

Oliver

Re: Vimode problem (key press dropping)

[Bart Schaefer]

On Jul 29,  6:45pm, Oliver Kiddle wrote:
}
} We could alleviate this issue by binding a few more keys by default at
} startup. Insert, Delete, Home, End, Page Up/Dn and the function keys
} all have termcap entries. Is there really a good reason not to bind at
} least the first four of these. What was the historical reason for not
} doing so?

Different terminals send different sequences for the same keys.  Also
you have to worry about whether the terminal is in keypad transmit mode
or not.  And the "same" terminal can behave differently when it's on
the far end of an ssh connection vs. when it's in a local console or
locally-running emulator.

So none of this can be hardwired, and it's a mess to calculate based on
the terminfo definition.  Duplicating the effort that programs like vim
and emacs go through to make this work has always seemed like overkill
for what's supposed to be a simple editor with minimal screen management.

This is why zkbd exists.

} Also, anyone know why the sequences for the cursors need to be
} passed through tputs()?

Some attempt to handle the keypad-transmit issue, I suspect.  I don't
recall; I think Wayne did the most recent work here, but I may be wrong
about that too.

} I also wonder whether we should consider trying to do something for
} Ctrl/Alt Left and Right to make it easier for new users.

A fair number of the terminals I use don't differentiate those modifier
keys in any useful way except when combining with non-alphabetics (and in
some caes not even then for e.g. the meta key).  My feeling has always
been that it's not a good idea to promise things we can't deliver.

Re: Vimode problem (key press dropping)

[Bart Schaefer]

On Jul 29, 10:49am, Bart Schaefer wrote:
}
} A fair number of the terminals I use don't differentiate those modifier
} keys in any useful way except when combining with non-alphabetics

Scratch one of "except" or "non-" from that sentence.  Sorry.

Re: Vimode problem (key press dropping)

[alx741]

On 2015-07-29 04:26, Oliver Kiddle wrote:
> The problem is that from vi command mode, the escape key is not bound 
> to
> anything. If you bind escape to do absolutely nothing, the problem goes
> away.
> 
>   bindkey -as '\e' ''
> 
> Or alternatively, the following is what vim does:
> 
>   bindkey -a '\e' beep
> 
> Oliver

That solved the problem!, thank you very much!