tui: never flush buffers in midst of unibilium output

e83845285 fixed an issue where long (true color) escape sequences got
interrupted by the cursor visibility toggling caused by buffer flushes.

cdfaecb25 introduces a new issue which causes similar problems: While
the old buffer flushing code appended the cursor visibility escapes to
the buffer before/after flushing, the new code effectively prepends the
sequences.

Assume the following sequence of events occurs:

 - A long escape code is issued using unibi_out when the buffer is
   almost full
 - out() gets called for a prefix of that escape code, causing the
   buffer to fill up
 - flush_buf(ui, false) is called and (correctly) does not insert any
   cursor toggling escapes
 - The rest of the escape code is written into the now empty buffer
 - At some later point, some other part of nvim calls flush_buf(ui,
   true), which then toggles the cursor, corrupting the escape code

This could possibly also be fixed by tracking the state of the buffer
(i.e. does it contain a partially output escape code?), but this seems
fragile in the same way e83845285 turned out to be.

The root cause for all these problems is the mismatch between nvim's
(implicit) assumption that the buffer is flushable at any point in time
and the non-atomicity of unibilium's character based callback interface.
The proper fix (without modifying unibilium) is to ensure nvim's
assumption about the buffer state holds at all times.

To that end, add a "cork" flag which ensures one unibi_out-call never
splits its output across a buffer flush; if an escape code does not fit
into the current buffer, flush it without any part of the escape code in
it and insert the whole escape code in the emptied buffer. This is a
little more complex because it modifies the buffer in place rather than
printing into another buffer, checking the remaining space in the
terminal buffer and then memcpy'ing it.

0 files changed, 0 insertions, 0 deletions