Problem:
Any random ftplugin or other autocmd, can throw an error when
`:checktime` reloads a buffer. This causes a trace which makes it look
like an issue with `autoread.lua`.
vim.schedule callback: …/runtime/lua/nvim/autoread.lua:146:
FileType Autocommands for "*"..function <SNR>1_LoadFTPlugin[20] ..script
…/runtime/ftplugin/help.lua: Vim(runtime):E5113: Lua chunk:
…/runtime/lua/vim/treesitter.lua:216: Index out of bounds
stack traceback:
[C]: in function 'nvim_buf_get_text'
…/runtime/lua/vim/treesitter.lua:216: in function 'get_node_text'
…/runtime/lua/vim/treesitter/query.lua:558: in function 'handler'
…/runtime/lua/vim/treesitter/query.lua:843: in function '_match_predicates'
…/runtime/lua/vim/treesitter/query.lua:1082: in function '(for generator)'
…/runtime/ftplugin/help.lua:91: in function 'runnables'
…/runtime/ftplugin/help.lua:124: in main chunk
[C]: in function 'checktime'
…/runtime/lua/nvim/autoread.lua:146: in function <…/runtime/lua/nvim/autoread.lua:138>
Solution:
Use pcall() and surface the error via nvim_echo.
Problem:
Old 'autoread' only did `:checktime` on focus-change and shell (":!")
commands, and only for non-hidden buffers. Since 'autoread' is now
driven by OS filewatcher events, buffers are updated much more eagerly.
This should be surfaced to the user somehow, either via a carefully
placed notification, or a minimal UI indicator.
A "notification" would be noisy, unless it is conditional on specific
circumstances (e.g. when "many" buffers are updated).
Solution:
Use the existing 'busy' buffer-local option as a subtle hint about
activity.
Problem:
The 'autoread' option only checks for file changes reactively — on
FocusGained, :checktime, CmdlineEnter, etc. — by polling timestamps.
External changes are not detected until the user interacts with Neovim.
Solution:
Add a core module (runtime/lua/nvim/autoread.lua) enabled from
runtime/plugin/autoread.lua that watches each buffer's file using
vim._watch.watch() (libuv fs_event). On change detection it calls
:checktime, which invokes the existing buf_check_timestamp() logic
for reload/prompt handling. Watchers are managed via autocmds tied
to buffer lifecycle events and respect the 'autoread' option (global
and buffer-local).
Problem:
stdpath() may return a DOS 8.3 "shortened" filename, because Windows
truncates long usernames into `6ch~N` names in `TEMP/TMP` env vars.
We don't want to "leak" them into Nvim.
Solution:
For "run", pass `true` to `vim_FullName` to expand 8.3 filenames.
For "cache", call `os_realpath` to expand 8.3 filenames.
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
Problem:
* 'shellcmdflag' states that its default value is set according to the
value of 'shell', but this behavior is not yet implemented on Windows.
The same applies to 'shellpipe', 'shellredir', and 'shellxquote'.
* On Windows, Git is often installed in paths containing spaces, and we
still do not correctly resolve the sh executable name as described in
'shell'.
* On Windows, the default value of 'shellslash' is always `false`,
which causes Unix-like shells to interpret `\` in paths returned by
some functions as escape charaters.
Solution:
Use a simple rule table to detect common shells (e.g. `cmd`,
`powershell`, shells whose names contain `csh` or `sh`) and apply
best-effort defaults, while leaving more complex scenarios to user
configuration.
Problem:
On Windows, path separators may become inconsistent for various reasons,
which makes normalization quite painful.
Solution:
Normalize paths to `/` at the entry boundaries and always use it
internally, converting back only in rare cases where `\` is really
needed (e.g. cmd.exe/bat scripts?).
This is the first commit in a series of incremental steps.
Note:
* some funcs won't respect shellslash. e.g. `expand/fnamemodify`
* some funcs still respect shellslash, but will be updated in a follow
PR. e.g. `ex_pwd/f_chdir/f_getcwd`
* uv's built-in funcs always return `\`. e.g. `uv.cwd/uv.exepath`
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
This is a better way to prevent parallel tests from interfering with
each other, as there are many ways files can be created and deleted in
tests, so enforcing different file names is hard.
Using $TMPDIR can also work in most cases, but 'backipskip' etc. have
special defaults for $TMPDIR.
Symlink runtime/, src/, test/ and README.md to Xtest_xdg dir to make
tests more convenient (and symlinking test/ is required for busted).
Also, use README.md instead of test/README.md in the Ex mode inccommand
test, as test/README.md no longer contains 'N' char.
- Rename ".nvimlog" to "nvim.log"
- doesn't need to be "hidden"/dotfile
- ".log" extension helps with filetype detection
- Also rename "nvim/log" => "nvim/nvim.log"
Problem:
Temporary files from /tmp/ and /private/ paths clutter :oldfiles list.
Additionally, the documented Windows default (rA:,rB:) was never applied
due to a missing platform condition.
Solution:
Drop platform-specific shada differences and default to excluding
/tmp/ and /private/ paths.
Problem:
assert_log() only matches single lines. This was never an intentional
decision, it was merely a result of using read_file_list().
Note: any tests that indiscriminately match `.*` should be rewritten to
avoid (unlikely) "false positives". I checked all existing tests.
Solution:
Change assert_log() to match the concatenated lines instead of matching
per-line.
Problem:
Tests that need to check `nvim` CLI behavior (no RPC session) create
their own ad-hoc `system()` wrappers.
Solution:
- Use `n.spawn_wait` instead of `system()`.
- Bonus: this also improves the tests by explicitly checking for
`stdout` or `stderr`. And if a signal is raised, `ProcStream.status`
will reflect it.
Problem:
- API functions using `try_start` directly instead of `TRY_WRAP`, do not
surface the underlying error message, and instead show generic things
like "Failed to set buffer".
- Error handling code is duplicated in the API impl, instead of
delegating to the vim buffer/window handling logic.
Solution:
- Use `TRY_WRAP`.
## Problem
With 'winfixbuf' enabled, `nvim_win_set_buf` and `nvim_set_current_buf` fail
even if targeting the already-current buffer.
vim.wo.winfixbuf = true
vim.api.nvim_win_set_buf(0, 0)
vim.api.nvim_set_current_buf(0)
Solution:
Check for this condition.
Before calling "attach" a screen object is just a dummy container for
(row, col) values whose purpose is to be sent as part of the "attach"
function call anyway.
Just create the screen in an attached state directly. Keep the complete
(row, col, options) config together. It is still completely valid to
later detach and re-attach as needed, including to another session.
$NVIM_LOG_FILE: /Users/runner/work/neovim/neovim/build/.nvimlog
WRN 2024-09-08T21:48:13.279 ?.21134 vim_mktempdir:3281: $TMPDIR tempdir not a directory (or does not exist): TMPDIR-should-be-ignored
WRN 2024-09-08T21:48:13.312 ?.21137 vim_mktempdir:3281: $TMPDIR tempdir not a directory (or does not exist): TMPDIR-should-be-ignored
- `alter_slashes` belongs in `testutil.lua`, not `testnvim.lua`.
- `alter_slashes` is an unusual name. Rename it to `fix_slashes`.
- invert its behavior, to emphasize that `/` slashes are the preferred,
pervasive convention, not `\` slashes.
Problem:
If $NVIM_APPNAME is a relative dir path, Nvim fails to start its
primary/default server, and `v:servername` is empty.
Root cause is d34c64e342, but this wasn't
noticed until 96128a5076 started reporting the error more loudly.
Solution:
- `server_address_new`: replace slashes "/" in the appname before using
it as a servername.
- `vim_mktempdir`: always prefer the system-wide top-level "nvim.user/"
directory. That isn't intended to be specific to NVIM_APPNAME; rather,
each *subdirectory* ("nvim.user/xxx") is owned by each Nvim instance.
Nvim "apps" can be identified by the server socket(s) stored in those
per-Nvim subdirs.
fix#30256
Problem:
`nvim --listen` does not error on EADDRINUSE. #30123
Solution:
Now that `$NVIM_LISTEN_ADDRESS` is deprecated and input *only* (instead
of the old, ambiguous situation where it was both an input *and* an
output), we can be fail fast instead of trying to "recover". This
reverts the "recovery" behavior of
704ba4151e, but that was basically
a workaround for the fragility of `$NVIM_LISTEN_ADDRESS`.
Specifically, functions that are run in the context of the test runner
are put in module `test/testutil.lua` while the functions that are run
in the context of the test session are put in
`test/functional/testnvim.lua`.
Closes https://github.com/neovim/neovim/issues/27004.
Also close Nvim instance before removing log file, otherwise the Nvim
instance will still write to the log file.
Also adjust log level in libuv_process_spawn(). Ref #27660
This is the first installment of a multi-PR series significantly
refactoring how highlights are being specified.
The end goal is to have a base set of 20 ish most common highlights,
and then specific files only need to add more groups to that as needed.
As a complicating factor, we also want to migrate to the new default
color scheme eventually. But by sharing a base set, that future PR
will hopefully be a lot smaller since a lot of tests will be migrated
just simply by updating the base set in place.
As a first step, fix the anti-pattern than Screen defaults to ignoring
highlights. Highlights are integral part of the screen state, not
something "extra" which we only test "sometimes". For now, we still
allow opt-out via the intentionally ugly
screen._default_attr_ids = nil
The end goal is to get rid of all of these eventually (which will be
easier as part of the color scheme migration)
Problem: too vague errors for 'listchars'/'fillchars'
Solution: Include the field name in error message.
(zeertzjq)
related: #27050closes: vim/vim#138776a8d2e1634
Co-authored-by: Cole Frankenhoff <cole.nhf@gmail.com>
A bit big, but practically it was a lot simpler to change over all
fillchars and all listchars at once, to not need to maintain two
parallel implementations.
This is mostly an internal refactor, but it also removes an arbitrary
limitation: that 'fillchars' and 'listchars' values can only be
single-codepoint characters. Now any character which fits into a single
screen cell can be used.
