This is a sham. if the user does
hi ExistingGroup guifg=AliceBlue invalidkey=foobar
the "guifg" part will still be executed. No need to micro-manage
the same case where ANewGroup is added instead.
`nvim_get_option_value` and `nvim_set_option_value` better handle
unsetting local options. For instance, this is currently not possible:
vim.bo.tagfunc = nil
This does not work because 'tagfunc' is marked as "local to buffer" and
does not have a fallback global option. However, using :setlocal *does*
work as expected
:setlocal tagfunc=
`nvim_set_option_value` behaves more like :set and :setlocal (by
design), so using these as the underlying API functions beneath vim.bo
and vim.wo makes those two tables act more like :setlocal. Note that
vim.o *already* uses `nvim_set_option_value` under the hood, so that
vim.o behaves like :set.
Problem: Various small issues.
Solution: Various small improvments.
8088ae95bb
N/A patches for version.c:
vim-patch:8.2.5107: some callers of rettv_list_alloc() check for not OK
Problem: Some callers of rettv_list_alloc() check for not OK. (Christ van
Willegen)
Solution: Use "==" instead of "!=" when checking the return value.
93a1096fe4
Note for external UIs: Nvim can now emit multiple "redraw" event batches
before a final "flush" event is received. To retain existing behavior,
clients should make sure to update visible state at an explicit "flush"
event, not just the end of a "redraw" batch of event.
* Get rid of copy_object() blizzard in the auto-generated ui_event layer
* Special case "grid_line" by encoding screen state directly to
msgpack events with no intermediate API events.
* Get rid of the arcane notion of referring to the screen as the "shell"
* Array and Dictionary are kvec_t:s, so define them as such.
* Allow kvec_t:s, such as Arrays and Dictionaries, to be allocated with
a predetermined size within an arena.
* Eliminate redundant capacity checking when filling such kvec_t:s
with values.
FindLua.cmake is a copy from the cmake repo:
0419ecbcad/Modules/FindLua.cmake.
It's a cmake module, meaning it's already shipped with cmake by default.
There have been two changes done to our version of FindLua.cmake.
The first change is that
include(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
was changed to
include(FindPackageHandleStandardArgs.cmake)
This change is required only because we have imported FindLua.cmake
module but not FindPackageHandleStandardArgs module. Had FindLua been
called as a module as intended then this file would not need changing.
The second change is that support for Lua 5.4 is added. However, support
for any version of Lua except for 5.1 is disabled since
e322b5c864.
Because these changes from the upstream FindLua.cmake is unnecessary I
believe we can and should use the builtin FindLua.cmake instead of our
own.
Instead of appending to a command output, append to an existing target
instead. The primary benefit is intermediary ...-cmd targets aren't
needed, we can instead append commands to the relevant target directly.
More specifically, replace exec_program with file(REMOVE ...) so that
the uninstall target is run during the build stage instead of the
configure stage, significantly speeding up the target.
The code snippet that was removed is taken from the cmake FAQ
https://gitlab.kitware.com/cmake/community/-/wikis/FAQ#can-i-do-make-uninstall-with-cmake.
However, this uses undocumented features such as IMMEDIATE when calling
configure_file, which is an artifact from cmake 2.x (it's so old it's
difficult to find information on it). Similarly, this particular code
snippet has been around for a long time and originated from the cmake
mailing lists. Based on this I believe the in-file was a workaround for
the limitations of cmake back then and that it's not required anymore.
Problem:
Piping NodeJS output into Neovim makes the editor unusable.
This happens because NodeJS changes the tty state on exit after
Nvim calls uv_tty_set_mode(). (May not always happen due to race
condition.)
This should have been fixed by 4ba5b4a864#13084. But some
commands and functions (:sleep, system(), …) call ui_flush()
internally, in particular the first tui_mode_change() is called before
the end of startup.
Steps to reproduce:
1. node -e "setTimeout(()=>{console.log('test')}, 1000)" | nvim -u NORC +"sleep 500m" -
2. The cursor key letters just overwrite the editor screen, and CTRL+C exits.
Solution:
Skip pending_mode_update during startup.
Note: Delaying ui_flush() entirely could be a more general solution
(emit a new UI event on VimEnter?). But "remote/coprocess TUI" #18375
could make all of this moot anyway.
Fixes#18470
Problem:
The release script bundles a system library (CoreServices) that was
added in #18294, which leads to errors on M1 since the architecture is
different from the Github runner.
Solution:
Skip CoreServices when bundling the libraries (as was done for the
CoreFoundation library that #18294 replaced with CoreServices).
Problem:
1. CI logs have too many (40+) logs mentioning SIGHUP:
```
WRN 2022-06-18T16:05:47.075 T3568.22499.0/c deadly_signal:177: got signal 1 (SIGHUP)
WRN 2022-06-18T16:05:47.273 T3569.91095.0/c deadly_signal:177: got signal 1 (SIGHUP)
WRN 2022-06-18T16:05:47.651 T3570.59545.0/c deadly_signal:177: got signal 1 (SIGHUP)
```
2. TS parser test still sometimes fails on BSD CI.
3. remote_spec test fails too often.
Solution:
1. Log deadly signals at INFO level. It hasn't been helpful in CI, and
for local troubleshooting it's reasonable to adjust the loglevel as
needed.
2. Adjust the TS parser test again. ref #18911
3. Skip the remote_spec test. The `--remote` feature was merged before
it was fully formed and needs to be revisited.
luacheck and clint are the most important, and they are bundled.
The others are nice-to-have, and not always available (and not bundled),
so make them optional. This allows the "lint" target to function as
a convenient and low-hassle handle for contributors.
We still get the full power of lint in CI.
TODO: bundle uncrustify (and then set it as required for "lint")?
Problem:
Coverity reports use after free:
*** CID 352784: Memory - illegal accesses (USE_AFTER_FREE)
/src/nvim/buffer.c: 1508 in set_curbuf()
1502 if (old_tw != curbuf->b_p_tw) {
1503 check_colorcolumn(curwin);
1504 }
1505 }
1506
1507 if (bufref_valid(&prevbufref) && prevbuf->terminal != NULL) {
>>> CID 352784: Memory - illegal accesses (USE_AFTER_FREE)
>>> Calling "terminal_check_size" dereferences freed pointer "prevbuf->terminal".
1508 terminal_check_size(prevbuf->terminal);
1509 }
1510 }
1511
1512 /// Enter a new current buffer.
1513 /// Old curbuf must have been abandoned already! This also means "curbuf" may
Solution:
Change terminal_destroy and terminal_close to set caller storage to NULL,
similar to XFREE_CLEAR. This aligns with the pattern found already in:
terminal_destroy e897ccad3e
term_delayed_free 3e59c1e20d
Problem:
If startup finishes (starting=false) before the logger ever happens to
see a v:servername, we're stuck with the "?.<PID>" fallback name
forever.
Solution:
Drop the `starting` condition. Discard the "?.<PID>" fallback after
using it for the current log message. So logging will always check
v:servername next time.
If `use_rgb` was false, we would attempt to set the `cterm_bg_color` to the
variable `bg`, which is only retrieved from `bg` and `background` keys, not
`ctermbg`. Same for `fg`. This means the values would be `-1` (the default,
un-got value) and we'd always set the returned values to `0`.
My understanding is `fg/bg` is always "gui" values, so instead we should be
using `ctermbg` when needed.
Nb: when looking around I think this function is currently *always* called with
`use_rgb = true`.
Fixes#18980
- 831fa45ad8 is related but this doesn't regress that
- The `cterm_normal_fg_color != ae.cterm_fg_color` comparison is originally
carried from patch to patch starting all the way back in 29bc6dfabd where it
was avoiding setting a HL attr. But `hlattrs2dict()` now is just
informational.
The current emulation script enters Insert mode much too frequently.
Using only BufWinEnter seems to be a closer simulation.
Also add a few more mappings.
Steps to reproduce:
1. setting `vim.highlight.on_yank`
```
vim.api.nvim_create_autocmd({ "TextYankPost" }, {
pattern = { "*" },
callback = function()
vim.highlight.on_yank({ timeout = 200 })
end,
})
```
2. repeat typing `yeye` ...
3. causes the following error.
```
Error executing vim.schedule lua callback: vim/_editor.lua:0: handle 0x01e96970 is already closing
stack traceback:
[C]: in function 'close'
vim/_editor.lua: in function ''
vim/_editor.lua: in function <vim/_editor.lua:0>
```
📝 Test result before fix:
[----------] Global test environment setup.
[----------] Running tests from test/functional/lua/highlight_spec.lua
[ RUN ] vim.highlight.on_yank does not show errors even if buffer is wiped before timeout: 15.07 ms OK
[ RUN ] vim.highlight.on_yank does not show errors even if executed between timeout and clearing highlight: 15.07 ms ERR
test/helpers.lua:73: Expected objects to be the same.
Passed in:
(string) 'Error executing vim.schedule lua callback: vim/_editor.lua:0: handle 0x02025260 is already closing
stack traceback:
[C]: in function 'close'
vim/_editor.lua: in function ''
vim/_editor.lua: in function <vim/_editor.lua:0>'
Expected:
(string) ''
Problem:
- Unix sockets are created in random /tmp dirs.
- /tmp is messy, unclear when OSes actually clear it.
- The generated paths are very ugly. This adds friction to reasoning
about which paths belong to which Nvim instances.
- No way to provide a human-friendly way to identify Nvim instances in
logs or server addresses.
Solution:
- Store unix sockets in stdpath('state')
- Allow --listen "name" and serverstart("name") to given a name (which
is appended to a generated path).
TODO:
- is stdpath(state) the right place?
Problem:
1. Log messages (especially in CI) are hard to correlate with tests.
2. Since b353a5c05f#11886, dumplog() prints the logs next to test
failures. This is noisy and gets in the way of the test results.
Solution:
1. Associate an incrementing id with each test and include it in log
messages.
- FUTURE: add v:name so Nvim instances can be formally "named"?
2. Mention "child" in log messages if the current Nvim is a child (based
on the presence of $NVIM).
BEFORE:
DBG … 12345 UI: event
DBG … 12345 log_server_msg:722: RPC ->ch 1: …
DBG … 12345 UI: flush
DBG … 12345 inbuf_poll:444: blocking... events_enabled=1 events_pending=0
DBG … 23454 UI: stop
INF … 23454 os_exit:594: Nvim exit: 0
AFTER:
DBG … T57 UI: event
DBG … T57 log_server_msg:722: RPC ->ch 1: …
DBG … T57 UI: flush
DBG … T57 inbuf_poll:444: blocking... events_enabled=1 events_pending=0
DBG … T57/child UI: stop
INF … T57/child os_exit:594: Nvim exit: 0
