Post by Kaz KylhekuPost by Julieta ShemPost by Kaz KylhekuPost by Janis PapanagnouYour proposal also works with TCSAFLUSH, so TCSANOW at least doesn't
seem necessary. Since you said I should "try" TCSANOW - which seemed
to imply no strict reason to use it - I also wanted to give feedback
on that part.
TCSAFLUSH is evil; if your user is a fast typist who can enter keyboard
input before your program has initialized, they will find that their
buffered keystrokes were lost. You won't easily see it in a small
program whose executable and libraries are cache hot, and which doesn't
read a lot of startup files and such.
(Vim does this annoying flush thing. I posted about it to the mailing
list many years ago and was rudely dismissed.)
Lol. Do you have a message-id or something? I'd love to have a look.
According to my own mail archives, I first posted about it to the
"Typeahead character loss when running Vim.".
prepended, on 2014-02-18, almost two years later.
I don't see any of the replies in my archives, though I subscribed
to the list at the time. I might have looked at the archive for
the reply.
You got two replies in 2014. Have a look at
https://groups.google.com/g/vim_use/c/XX6SoxHAzhI
That's how nice it is to have a decent USENET archive. Soon we won't
count on this one, but we won't miss the spam either. Speaking of
Google Groups, it is itself the archive pointed out by the vim mail list
homepage at https://www.vim.org/maillist.php. Now, when I went to the
archive, I could not find your message at all, but duckduckgo.com
readily located at Google Groups. (It's nice to have an archive, even
if it's not searchable.)
What e-mail client were you using then? It seems to have inserted line
breaks not where you really wanted.
(*) Your message
--8<---------------cut here---------------start------------->8---
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.
Post by Kaz KylhekuI'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.
--8<---------------cut here---------------end--------------->8---
(*) Reply by Gary Johnson
--8<---------------cut here---------------start------------->8---
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
--8<---------------cut here---------------end--------------->8---
(*) Reply by Tony Mechelynck
--8<---------------cut here---------------start------------->8---
Post by Kaz KylhekuHello?
I asked this nearly two years ago; doesn't anyone else have this problem?
Is it fixed in newer versions of Vim?
$ 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!!
--8<---------------cut here---------------end--------------->8---