This enables vim.filetype.match to match based on a buffer (most
accurate) or simply a filename or file contents, which are less accurate
but may still be useful for some scenarios.
When matching based on a buffer, the buffer's name and contents are both
used to do full filetype matching. When using a filename, if the file
exists the file is loaded into a buffer and full filetype detection is
performed. If the file does not exist then filetype matching is only
performed against the filename itself. Content-based matching does the
equivalent of scripts.vim, and matches solely based on file contents
without any information from the name of the file itself (e.g. for
shebangs).
BREAKING CHANGE: use `vim.filetype.match({buf = bufnr})` instead
of `vim.filetype.match(name, bufnr)`
Problem:
Nvim fails to create tempfile "…/nvim6UJx04/7" when 'shell' is set to
pwsh (PowerShell Core). This breaks filtered shell commands ":{range}!".
With shell set to cmd, it works.
Solution:
PowerShell doesn't use "<" for stdin redirection. Instead, use
"-RedirectStandardInput".
Closes#15913
Problem:
RunTests.cmake adds $TEST_PATH to $TMPDIR with the implication that it
gives more isolation. But this is misleading because $TEST_PATH is only
defined once. Full test runs use the same $TMPDIR for all tests.
This was likely added with the intention of invoking RunTests.cmake
once-per-testfile from a wrapper than does the isolation/orchestration.
But even so, Nvim's vim_maketempdir() / vim_mktempdir() _already_
creates a unique tempdir per session.
Solution:
Don't append $TEST_PATH to $TMPDIR. Avoids confusion and makes the path
shorter.
Avoids this warning in the Windows build:
2022-06-22T08:58:13.0542153Z LINK : warning LNK4044: unrecognized option '/municode'; ignored [D:\a\neovim\neovim\build\test\functional\fixtures\printenv-test.vcxproj]
global-local window options need to be handled specially. When `win` is
given but `scope` is not, then we want to set the local version of the
option but not the global one, therefore we need to force
`scope='local'`.
Note this does not apply to window-local only options (e.g. 'number')
Example:
nvim_set_option_value('scrolloff', 10, {}) -- global-local window option; set global value
nvim_set_option_value('scrolloff', 20, {win=0}) -- global-local window option; set local value
nvim_set_option_value('number', true, {}) -- local window option
is now equivalent to:
nvim_set_option_value('scrolloff', 10, {})
nvim_set_option_value('scrolloff', 20, {win=0, scope='local'}) -- changed from before
nvim_set_option_value('number', true, {win=0}) -- unchanged from before
Only the global-local option with a `win` provided gets forced to local
scope.
`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.
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.
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.
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.
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
There can be other places that access window buffer info (e.g.
`tabpagebuflist()`), so checking `w_closing` in `win_findbuf()` doesn't
solve the crash in all cases, and may also cause Nvim's behavior to
diverge from Vim.
Fix#14998
Command preview now behaves like inccommand=nosplit when there's not
enough room for the preview window to be opened instead of aborting,
which is consistent with old behavior of 'inccommand'.
Many filetypes from filetype.vim set buffer-local variables, meaning
vim.filetype.match cannot be used without side effects. Instead of
setting these buffer-local variables in the filetype detection functions
themselves, have vim.filetype.match return an optional function value
that, when called, sets these variables. This allows vim.filetype.match
to work without side effects.
The "first run" has high variability. Looks like the test failures
correlate with 545dc82c1b
, which makes sense because that improves "first run" performance.
So the `1000*` factor of this test could be adjusted to e.g. `300*` or `500*`.
ref https://github.com/neovim/neovim/pull/16945
