I've figured out that on some startups this if statement https://github.com/neovim/neovim/blob/master/src/nvim/tui/input.c#L406 is entered and sometimes it isn't.

Vim also has an implementation of background detection, which seems to work fine.

alacritty decided to do it a different way. Vim patches:

• vim/vim@32e1977
• vim/vim@12e71eb

Patch welcome.

cc @joshtriplett

That still doesn't explain why https://github.com/neovim/neovim/blob/master/src/nvim/tui/input.c#L406 is sometimes entered and sometimes it isn't.

I've wrote a small C program that checked how many characters were read() on one invocation (the return value of read()).

Where termite (libvte) always returned 24 characters (^[]11;rgb:fbfb/f1f1/c7c7^G),

Alacritty returned different results. Sometimes 18 chars (^[]11;rgb:fb/f1/c7^G), but sometimes it's split. I've seen (17,1), (2,16), (2,2,5,2,3,4)...

Vim also has an implementation of background detection, which seems to work fine.

alacritty decided to do it a different way. Vim patches:

* [vim/vim@32e1977](https://github.com/vim/vim/commit/32e1977012912cd5d7bc762dd41197bc3f1a1370)

* [vim/vim@12e71eb](https://github.com/vim/vim/commit/12e71eb8a89bdfe1def5854fd7478e8899801b44)

Patch welcome.

cc @joshtriplett

This comment https://github.com/neovim/neovim/blob/master/src/nvim/tui/input.c#L387 and if I'm reading the code correct suggests different lengths of RGB are parsed correctly.

I think #10131 (comment) is the real issue here. I haven't dug into the Vim source code, but I assume it will just sit and wait for a complete response to \x1b]11;?\x07?

#10195 mentions this might crash even.
Can you please provide a stacktrace for this? (see https://github.com/neovim/neovim/wiki/Development-tips#debugging)
(might be as easy as coredumpctl gdb, and then bt)

Master (v0.4.0-1016-g6f27f5ef9) doesn't seem to crash anymore for me, btw (or it hasn't crashed so far in 5mins of trying to crash it). Anecdotally, it seems like master is a lot less likely to get garbage chars at startup also

I stand corrected. It also crashes on v0.4.0-1016-g6f27f5ef9 but it seems a lot less frequent. Same error as I mentioned in #10195 and I don't have symbols in this build so that stack is basically useless (sorry).

@HarmtH
Is this related to / fixed by #10205 ?

@HarmtH
Is this related to / fixed by #10205 ?

No, different problems unfortunately.

The issue here is that, unlike other terminals, Alacritty's response is not always contained in one read() call. (I'm not enough of a kernel expert to know whether it's guaranteed that the responses from other terminals will be contained in one read() call, but it happens to be the case.)

Neovim will crash when only ^[]11;rgb: is in the rbuffer.
The loop will be entered https://github.com/neovim/neovim/blob/master/src/nvim/tui/input.c#L411
But there is nothing left to read https://github.com/neovim/neovim/blob/master/src/nvim/tui/input.c#L422
So count will stay 0
And the assertion count && count <= buf->size inside https://github.com/neovim/neovim/blob/master/src/nvim/tui/input.c#L445 will trigger.

So fixing the crash is as easy as wrapping https://github.com/neovim/neovim/blob/master/src/nvim/tui/input.c#L445 in an if (count) {}.

Fixing the garbage typing will be a bit more difficult.

From a quick look it seems like tinput_read_cb should be responsible for handling / passing on only complete/finished escape sequences from responses?
Ok, rather handle_background_color should postpone the handling if not complete (yet) maybe?

From a quick look it seems like tinput_read_cb should be responsible for handling / passing on only complete/finished escape sequences from responses?

It seems to me that it cuts the input stream so the escape character doesn't appear in the middle, but always at the start. But it doesn't seem that it will wait for a complete sequence when it's already at the start?

Ok, rather handle_background_color should postpone the handling if not complete (yet) maybe?

That sounds like an idea, but therefore tinput_read_cb first needs to be able to wait for complete sequences, probably with a time-out so it won't wait forever.

This has just been reported to me in jwilm/alacritty#2543.

While looking into it, I came to the same conclusion that this must be because the output is not written in a single go and I'll see if I can patch this in Alacritty.

Regarding the format, this is planned to change to the more common rgb:ffff/0000/ffff format, however it should probably be noted that even #fff000fff is a valid format. Full info about allowed color formats can be found in man XParseColor.

Split reads/writes are not a bug, but an explicit result of the termios settings used by neovim.

As noted in the termios(3) man page, there are almost no guarantees about the result of a read:

The settings of MIN (c_cc[VMIN]) and TIME (c_cc[VTIME]) determine the circumstances in which a read completes; there are four distinct cases:

...

MIN > 0, TIME == 0 (blocking read)
read blocks until MIN bytes are available, and returns up to the number of bytes requested.

Applications shouldn't be relying on the terminal to never split escape sequences across multiple writes -- they should either be waiting for the sequence terminator or detecting truncation then re-reading and re-parsing. Most apps that handle it at all do the latter.