On 2023-12-21, Julieta Shem <jshem@yaxenu.org> wrote:
> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>
>> On 2023-12-20, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>> Your 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
vim@vim.org mailing list on 2012-03-27 with the subject
"Typeahead character loss when running Vim.".

I think I got no reply, so I pinged the topic, sme subject line with Re:
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.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

Kaz Kylheku <433-929-6894@kylheku.com> writes:

> On 2023-12-21, Julieta Shem <jshem@yaxenu.org> wrote:
>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>>
>>> On 2023-12-20, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>>> Your 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
> vim@vim.org mailing list on 2012-03-27 with the subject
> "Typeahead character loss when running Vim.".
>
> I think I got no reply, so I pinged the topic, sme subject line with Re:
> 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.

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.
--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---
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!!
--8<---------------cut here---------------end--------------->8---

On 2023-12-22, Julieta Shem wrote:

> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>
>> On 2023-12-21, Julieta Shem <jshem@yaxenu.org> wrote:
>>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
[...]
>>>> 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
>> vim@vim.org mailing list on 2012-03-27 with the subject
>> "Typeahead character loss when running Vim.".
>>
>> I think I got no reply, so I pinged the topic, sme subject line with Re:
>> 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

[...]

The post I'm replying to already has the contents of the 2014 post and
of its two replies, I'm just mentioning the Message-IDs in case these
are useful (although, as this is a mailing list, it's possible Google
groups actually does give access to the Message-IDs?):

The 2012 post:
- <64a254c0-ac6e-4492-9931-703430ed7708@mq9g2000pbb.googlegroups.com>

The 2014 posts:
- <172e41b39c870080ba1ceae3774ca678@mail.kylheku.com>
- <20140219031500.GD1648@phoenix>
- <530442A1.7020708@gmail.com>

These are all on gmane too. If you have a browser that can load news:
URLs:
- news://news.gmane.io/64a254c0-ac6e-4492-9931-703430ed7708@mq9g2000pbb.googlegroups.com
- news://news.gmane.io/172e41b39c870080ba1ceae3774ca678@mail.kylheku.com
- news://news.gmane.io/20140219031500.GD1648@phoenix
- news://news.gmane.io/530442A1.7020708@gmail.com

(I don't see line break issues in the 2014 posts, is it possible these
are being added by the google groups interface?)

--
Nuno Silva

On 22.12.2023 06:33, Julieta Shem wrote:
> [ from the archives; character loss on Vim startup ]

> On 27.03.2012 14:33, Kaz Kylheku wrote:
>>
>> 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.

For this specific but not uncommon usecase - to start and immediately
locate the desired place - you could work around the issue by starting

$ vim +/quicksort file.txt

instead of

$ vim file.txt
/quicksort

Doesn't address the Vim issue directly but may result in a better user
experience of the interface for fast typers.

(It certainly will be difficult to change habits, though, to relocate
the first command to the vim call. Myself I also first start the tool.)

Janis

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

> On 22.12.2023 06:33, Julieta Shem wrote:
>> [ from the archives; character loss on Vim startup ]
>
>> On 27.03.2012 14:33, Kaz Kylheku wrote:
>>>
>>> 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.
>
> For this specific but not uncommon usecase - to start and immediately
> locate the desired place - you could work around the issue by starting
>
> $ vim +/quicksort file.txt
>
> instead of
>
> $ vim file.txt
> /quicksort
>
> Doesn't address the Vim issue directly but may result in a better user
> experience of the interface for fast typers.
>
> (It certainly will be difficult to change habits, though, to relocate
> the first command to the vim call. Myself I also first start the tool.)

I would bet Kaz Kylheku was just reporting the flaw, which apparently
the maintainers of the software couldn't care enough. Is that why we
all run EMACS? :-)

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 19.12.2023 18:04, Scott Lurndal wrote:
>>
>> Use poll(2) instead of read(2). [...]
>
> int poll(struct pollfd *fds, nfds_t nfds, int timeout);
>
> It isn't explicitly mentioned in the man-page, but I assume a
> timeout value of 0 will actually do the non-blocking behavior
> with poll(2).

SUS says

If the value of timeout is 0, poll() shall return immediately.

https://pubs.opengroup.org/onlinepubs/9699919799/functions/poll.html

The Linux man page has this as

Specifying a timeout of zero causes poll() to return immediately, even
if no file descriptors are ready.