Re: Typeahead character loss when running Vim.

[Kaz Kylheku]

Hello?

I asked this nearly two years ago; doesn't anyone else have this
problem?

Is it fixed in newer versions of Vim?

On an Ubuntu 11.04 which has a dated version of Vim, if I do this:

$ vim some_file

and upon hitting enter, immediately type, "io", sometimes Vim ends up in
command mode as if nothing was typed, then sometimes it ends up in an
insert on the same line, and the character o has been entered, as
expected.
Most of the time, though, one of the other four possibilities happens,
based on which of the two characters is dropped, or both: it's in
command
mode, insert mode on the same line, or insert mdoe with a new line
having
been o)pened.


On 27.03.2012 14:33, Kaz Kylheku wrote:
> I'm using Vim 7.3 on Ubuntu 11.x.
>
> When I run $ vim file.txt from the shell, and start typing a command
> like /quicksort,
> some of the characters end up missing. It might end up /quickt.
>
> I type very fast and can queue up quite a bunch of keystrokes, which I
> expect to be executed properly.
>
> This is especially annoying when the character loss turns a harmless
> positioning
> command into an edit which then has to be undone.
>
> Looks like Vim may be discarding some characters (or telling the TTY
> driver to do that).

--
Memorize Japanese Characters with Tankan.

[Gary Johnson]

I had this problem years ago at a different company when I had an X
server running on my desktop machine and I ran vim on a server in
the back room. I think the terminal was running on the desktop
machine.

As I recall, the problem was due to the terminal response sequence
arriving late so that vim thought all or part of it was coming from
the keyboard. Also as I recall, my solution was to set t_RV to an
empty string and set 'ttymouse' to "xterm2" since vim was then
unable to determine the value of 'ttymouse' from the terminal
response.

To find out more about t_RV,

:helpgrep t_RV

I don't know if this has been fixed or not. I haven't seen the
problem since changing companies and running everything on the
back-room servers with NoMachine on my Windows desktop. I did see a
problem for a while with the terminal response sequence interfering
with vimdiffs, but I haven't seen that for maybe a year.

HTH,
Gary

[Tony Mechelynck]

On 19/02/14 01:36, Kaz Kylheku wrote:
> Hello?
>
> I asked this nearly two years ago; doesn't anyone else have this problem?
>
> Is it fixed in newer versions of Vim?
>
> On an Ubuntu 11.04 which has a dated version of Vim, if I do this:
>
> $ vim some_file
>
> and upon hitting enter, immediately type, "io", sometimes Vim ends up in
> command mode as if nothing was typed, then sometimes it ends up in an
> insert on the same line, and the character o has been entered, as expected.
> Most of the time, though, one of the other four possibilities happens,
> based on which of the two characters is dropped, or both: it's in command
> mode, insert mode on the same line, or insert mdoe with a new line having
> been o)pened.

If you type something "immediately" after invoking Vim from the sh
command-line, then there is a race condition between the human typing at
the keyboard and the system loading and starting Vim. I would expect
that the io input would or would not be received, or even might be
received only partly, by Vim, depending on who wins the race.

A possible reason for this race condition to exist (rather than Vim
using the system's keyboard-typeahead buffer as found as startup) is
that when running in an xterm, Vim tries to determine the xterm version
by querying the xterm (sending a control command to the "display") and
waiting for a corresponding response stream of control characters on its
"keyboard" input line. If this is the case you should not experience any
loss in the non-X Linux consoles (accessed by Ctrl-Alt-F1 to
Ctrl-Alt-F6; come back to X by Ctrl-Alt-F7 or Ctrl-Alt-F8 depending on
"I don't know what").

IMHO the "healthy" way to proceed would be for the human to wait on Vim
displaying either the ":intro" splash screen or the contents of the
first editfile before proceeding to type anything at the keyboard. This
way (i.e. with a wait loop inserted into the human's firmware) it can be
guaranteed that there is no race condition, and that Vim is always in a
known state when the first keyboard byte is sent to the console or X
interface.


Best regards,
Tony.
--
I think I'll KILL myself by leaping out of this 14th STORY WINDOW while
reading ERICA JONG'S poetry!!