The previous commit ensures that we can never flush the buffer in a
state where toggling cursor visibility can corrupt other escape codes.
Thus, we can remove the workaround added as part of e838452, simplyfing
the code and hiding the cursor on more occasions.
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.
Get terminal debugging info by starting Nvim with 'verbose' level 3:
nvim -V3log
This is like Vim's `:set termcap`, which was removed in Nvim (and would
be very awkward to restore because of the decoupled UI).
filter('v:_null_list, 'v:val') should return v:_null_list and a similar
statement should hold for map.
Changes after review
* Test inserted in legacy test suite has been removed by reverting the commit
adding it.
* Change the fix to tv_copy the argument before returning.
* Readd the two tests on crashes, and modified their expected return value.
* Move the test from 'incorrect behaviour' section to 'correct behaviour section'
* Add analogous tests for v:_null_dict
Always copy list or dictionary to return variable
If the type of input is correct (i.e. either a list or a dictionary), this
should also be returned.
ref #7649
ref #766427f9b1c7b0 caused a regression: it uses loop_schedule_deferred() to
defer emitting the "enable focus reporting" termcode. tui_main() never
processes `tui_loop.events` (which loop_schedule_deferred() depends on),
so the event was never actually processed.
But fixing that (by processing `tui_loop.events`) would bring back the
problem 27f9b1c7b0 tried to fix: it still emits the event too soon.
Instead, do a little dance: schedule the event on `main_loop` and then
forward it to `tui_loop`.
NOTE: after this commit, in tmux 2.3 with `focus-events` enabled,
FocusGained is fired on startup and when resuming from suspend.
Using `script` to record the terminal session (and `vterm-dump` to
post-process the result):
BEFORE:
{DECSM 1049}{DECSM 1}{ESC =}
{CUP *}{ED *}{DECSM 2004}{DECSM 1004}{CSI 1,43 r}
{CUP 1,1}
{CUP *}{ED *}{SM 34}{DECSM 25}
{DECRM 25}{CSI 2 q}{CSI 2 q}
{CUP *}{ED *}{LF}
{SGR *}{LS1}{SGR 94}~
...
AFTER:
{CUP *}{ED *}{CSI 1,43 r}
{CUP 1,1}
{CUP *}{ED *}{SM 34}{DECSM 25}
{DECRM 25}{CSI 2 q}{CSI 2 q}
{CUP *}{ED *}{DECSM 2004}{DECSM 1004}{LF}
{SGR *}{LS1}{SGR 94}~
...
Note: there are three changes to ascii_isident. Reverting first two (in
find_special_key and first in get_special_key_code) normally fails the new test
with empty &isident, but reverting the third does not. Hence adding `>` to
&isident.
Ref vim/vim#2389.
When building with certain GCC versions, a _Float128 type is present
when setting up the ffi for unit tests.
./test/unit/helpers.lua:256: declaration specifier expected near '_Float128' at line 396
/usr/bin/luajit: /usr/share/lua/5.1/busted/runner.lua:99: attempt to concatenate local 'message' (a table value)
stack traceback:
/usr/share/lua/5.1/busted/runner.lua:99: in function 'fn'
/usr/share/lua/5.1/mediator.lua:103: in function 'publish'
/usr/share/lua/5.1/busted/modules/helper_loader.lua:21: in function 'helperLoader'
/usr/share/lua/5.1/busted/runner.lua:147: in function </usr/share/lua/5.1/busted/runner.lua:11>
/usr/bin/busted:3: in main chunk
[C]: at 0x004044a0
CMake Error at /<<PKGBUILDDIR>>/cmake/RunTests.cmake:53 (message):
Running unit tests failed with error: 1.
Since this is being pulled in by a dependency, not directly used by
nvim, just ignore the type.
Closes#7423
ruby uses batchfiles with 'cmd' extension.
gem creates batchfiles with 'bat' extension.
`gem install rails` does the following in Windows (not Cygwin):
1. Run `gem.cmd install rails` on cmd.exe
2. gem.cmd runs `ruby.exe -x gem install rails`
3. `rails` gem is installed.
`rails.bat` is created in the same directory
where ruby.exe and gem.cmd reside.
- channels: vim-patch:8.0.0018
- GUI: vim-patch:8.0.0021
- Different recursive function implementation: vim-patch:8.0.0141
- JSON handling: vim-patch:8.0.0166, vim-patch:8.0.0169, vim-patch:8.0.0170,
vim-patch:8.0.0171, vim-patch:8.0.0180
Mark vim-patch:8.0.0096 applied, since it was added in
860ecd7055.
[ci skip]
