Problem:
CID 584865: Control flow issues (UNREACHABLE)
/src/nvim/lua/executor.c: 550 in nlua_wait()
>>> CID 584865: Control flow issues (UNREACHABLE)
>>> This code cannot be reached: "abort();".
550 abort();
551 }
Solution:
The abort() was intended to encourage explicit handling of all cases, to
avoid fallthrough to a possible `return x` added at the end. However,
this is unlikely so just drop it.
Continuing the work of #31400
That PR allowed the provider to be invoked multiple times per line.
We want only to do that when there actually is more data later on the
line. Additionally, we want to skip over lines which contain no new
highlight items. The TS query cursor already tells us what the next
position with more data is, so there is no need to reinvoke the range
callback before that.
NB: this removes the double buffering introduced in #32619 which
is funtamentally incompatible with this (nvim core is supposed to keep
track of long ranges by itself, without requiring a callback reinvoke
blitz). Need to adjust the priorities some other way to fix the same issue.
Problem:
The default progress message doesn't account for
message-status. Also, the title and percent sections don't get written
to history. And progress percent is hard to find with variable length messages.
Solution:
Apply highlighting on Title based on status. And sync the formated msg
in history too. Also updates the default progress message format to
{title}: {percent}% msg
Problem:
The callback passed to `vim.wait` cannot return results directly, it
must set upvalues or globals.
local rv1, rv2, rv3
local ok = vim.wait(200, function()
rv1, rv2, rv3 = 'a', 42, { ok = { 'yes' } }
return true
end)
Solution:
Let the callback return values after the first "status" result.
local ok, rv1, rv2, rv3 = vim.wait(200, function()
return true, 'a', 42, { ok = { 'yes' } }
end)
Problem:
Nvim does not have a core concept for indicating "progress" of
long-running tasks. The LspProgress event is specific to LSP.
Solution:
- `nvim_echo` can emit `kind="progress"` messages.
- Emits a `Progress` event.
- Includes new fields (id, status, percent) in the `msg_show` ui-event.
- The UI is expected to overwrite any message having the same id.
- Messages have a globally unique ID.
- `nvim_echo` returns the message ID.
- `nvim_echo(… {id=…})` updates existing messages.
Example:
local grp = vim.api.nvim_create_augroup("Msg", {clear = true})
vim.api.nvim_create_autocmd('Progress', {
pattern={"term"},
group = grp,
callback = function(ev)
print(string.format('event fired: %s', vim.inspect(ev))..'\n')
end
})
-- require('vim._extui').enable({enable=true, msg={target='msg', timeout=1000}})
vim.api.nvim_echo({{'searching'}}, true, {kind='progress', percent=80, status='running', title="terminal(ripgrep)"})
local id = vim.api.nvim_echo({{'searching'}}, true, {kind='progress', status='running', percent=10, title="terminal(ripgrep)"})
vim.api.nvim_echo({}, true, {id = id, kind='progress', percent=20, status = 'running', title='find tests'})
vim.api.nvim_echo({}, true, {id = id, kind='progress', status='running', percent=70})
vim.api.nvim_echo({{'complete'}}, true, {id = id, kind='progress', status='success', percent=100, title="find tests"})
Followups:
- Integrate with 'statusline' by listening to the Progress autocmd event.
- Integrate progress ui-event with `vim._extui`.
Problem:
with `foldmethod=expr foldexpr=v:lua.vim.treesitter.foldexpr()
foldminlines=0`, deleting lines at the end of the buffer always
reports an invalid top error, because the top value (i.e. the
start line number of the deletion) is always 1 greater than
the total line number of the modified buffer.
Solution:
remove the ml_line_count validation
These are not needed after #35129 but making uncrustify still play nice
with them was a bit tricky.
Unfortunately `uncrustify --update-config-with-doc` breaks strings
with backslashes. This issue has been reported upstream,
and in the meanwhile auto-update on every single run has been disabled.
Using the preprocessor before generating prototypes provides some
"niceties" but the places that rely on these are pretty few.
Vastly simplifying the BUILD SYSTEM is a better trade-off.
Unbalancing { } blocks due to the preprocessor is cringe anyway (think
of the tree-sitter trees!), write these in a different way.
Add some workarounds for plattform specific features.
INCLUDE_GENERATED_DECLARATIONS flag is now technically redundant,
but will be cleaned up in a follow-up PR as it is a big mess.
Problem:
The "gitsigns" plugin runs `vim.diff` in a thread (`uv.new_work`), but
`vim.diff` is nil in that context:
Lua callback:
…/gitsigns.nvim/lua/gitsigns/diff_int.lua:30: bad argument #1 to 'decode' (string expected, got nil)
stack traceback:
[C]: in function 'decode'
…/gitsigns.nvim/lua/gitsigns/diff_int.lua:30: in function <…/gitsigns.nvim/lua/gitsigns/diff_int.lua:29>
Luv thread:
…/gitsigns.nvim/lua/gitsigns/diff_int.lua:63: attempt to call field 'diff' (a nil value)
Solution:
Revert the `stdlib.c` change (set `vim.diff` instead of `vim._diff`).
Problem:
The previous fix in #34314 relies on copying the tree in `tree_root` to
ensure the `TSNode`'s tree cannot be mutated. But that causes the
problem where two calls to `tree_root` return nodes from different
copies of a tree, which do not compare as equal. This has broken at
least one plugin.
Solution:
Make all `TSTree`s on the Lua side always immutable, avoiding the need
to copy the tree in `tree_root`, and make the only mutation point,
`tree_edit`, copy the tree instead.
fix(exrc): lua exrc files know their location
Problem:
'exrc' files are inherently bound to their location / workspace and
therefore require to "know" their location on the filesystem. However,
currently using `debug.getinfo(1, 'S')` returns `"<nvim>"`.
Solution:
Include the filepath as chunkname in `loadstring()` and `nlua_exec()`.
Problem:
TSNode contains a `const TSTree*` and a `const void *id`. The `id`
points to Tree-sitter's internal type `Subtree`, which resides inside
the `TSTree` but may be deallocated if the `TSTree` is mutated (which
is likely why it is `const`).
The Lua method `TSTree:edit()` mutates the tree, which can deallocate
`id`.
See #25254 and #31758.
Solution:
To avoid this, we now make a copy of the tree before pushing its root to
the Lua stack. This also removes the fenv from TSLuaTree, as it was only
used when pushing the tree root to the Lua stack.
We also copy the tree in `node_tree`.
`ts_tree_copy()` just increments a couple of reference counters, so it's
relatively cheap to call.
Problem: nvim_create_user_command() Lua callbacks were missing the documented nargs field in the options table passed to the callback function.
Solution: Add nargs field derivation from command argument type flags in nlua_do_ucmd(), using the same logic as nvim_parse_cmd().
NEW BUILD SYSTEM!
This is a MVP implementation which supports building the "nvim" binary,
including cross-compilation for some targets.
As an example, you can build a aarch64-macos binary from
an x86-64-linux-gnu host, or vice versa
Add CI target for build.zig currently for functionaltests on linux
x86_64 only
Follow up items:
- praxis for version and dependency bumping
- windows 💀
- full integration of libintl and gettext (or a desicion not to)
- update help and API metadata files
- installation into a $PREFIX
- more tests and linters
Problem: We allow setting 'cmdheight' to 0 with ext_messages enabled
since b72931e7. Enabling ext_messages with vim.ui_attach()
implicitly sets 'cmdheight' to 0 for BWC. When non-zero
'cmdheight' is wanted, this behavior make it unnecessarily
hard to keep track of the user configured value.
Solution: Add set_cmdheight to vim.ui_attach() opts table that can be
set to false to avoid setting 'cmdheight' to 0.
Problem:
vim.uv.os_setenv gets "stuck" per-key. #32550
Caused by the internal `envmap` cache. #7920
:echo $FOO <-- prints nothing
:lua vim.uv.os_setenv("FOO", "bar")
:echo $FOO <-- prints bar (as expected)
:lua vim.uv.os_setenv("FOO", "fizz")
:echo $FOO <-- prints bar, still (not expected. Should be "fizz")
:lua vim.uv.os_unsetenv("FOO")
:echo $FOO <-- prints bar, still (not expected. Should be nothing)
:lua vim.uv.os_setenv("FOO", "buzz")
:echo $FOO <-- prints bar, still (not expected. Should be "buzz")
Solution:
- Remove the `envmap` cache.
- Callers to `os_getenv` must free the result.
- Update all call-sites.
- Introduce `os_getenv_noalloc`.
- Extend `os_env_exists()` the `nonempty` parameter.
Apparently after parsing with options in tree-sitter, the options data
persists in the parser object, and thus successive calls to
`ts_parser_parse()` will act like `ts_parser_parse_with_options()`. This
is problematic because `languagetree.lua` makes coroutine-environment
assumptions based on if a nullptr has been returned by the parser
function. This commit makes it so that the parse options state is reset
upon a regular parse (would be nice if this was done upstream).
Fixes#33277
Remove the `set_timeout` functions for `TSParser` and instead add a timeout
parameter to the regular parse function. Remove these deprecated tree-sitter
API functions and replace them with the preferred `TSParseOptions` style.
Problem: Error messages that cause a vim.ui_attach() namespace to
detach are not visible in the message history. Decoration
provider and vim.ui_attach error messages are dissimilar.
Solution: Emit vim.ui_attach() errors as an actual message in addition
to logging it. Adjust error message format.
Problem: Message kind logic for emitting an error message is convoluted
and still results in emitting an unfinished message earlier than
wanted.
Solution: Ensure emsg_multiline() always sets the kind wanted by the caller
and doesn't isn't unset to logic for emitting the source message.
Caller is responsible for making sure multiple message chunks are
not emitted as multiple events by setting `msg_ext_skip_flush`...
Problem: Cannot disable individual captures and patterns in treesitter queries.
Solution:
* Expose the corresponding tree-sitter API functions for `TSQuery` object.
* Add documentation for `TSQuery`.
* Return the pattern ID from `get_captures_at_pos()` (and hence `:Inspect!`).
Problem: No way to check the version of a treesitter parser.
Solution: Add version metadata (ABI 15 parsers only) as well as parser state count and supertype information (ABI 15) in `vim.treesitter.language.inspect()`. Also graduate the `abi_version` field, as this is now the official upstream name.
---------
Co-authored-by: Christian Clason <c.clason@uni-graz.at>
Problem: Sourcing buffer lines is too complicated.
Solution: Simplify the code. Make it possible to source Vim9 script lines.
(Yegappan Lakshmanan, closesvim/vim#9974)
85b43c6cb7
This commit changes the behavior of sourcing buffer lines to always have
a script ID, although sourcing the same buffer always produces the same
script ID.
vim-patch:9.1.0372: Calling CLEAR_FIELD() on the same struct twice
Problem: Calling CLEAR_FIELD() on the same struct twice.
Solution: Remove the second CLEAR_FIELD(). Move the assignment of
cookie.sourceing_lnum (zeertzjq).
closes: vim/vim#14627f68517c167
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Problem: Wrong script context for option set by function defined by
nvim_exec2 in a Lua script.
Solution: Call nlua_set_sctx() after adding SOURCING_LNUM and always set
sc_lnum for a Lua script.
This is a bug discovered when testing #28486. Not sure if this actually
happens in practice, but it's easy to fix and required for #28486.
Problem: When setting an option, mapping etc. from Lua without -V1, the
script ID is set to SID_LUA even if there already is a script
ID assigned by :source.
Solution: Don't set script ID to SID_LUA if it is already a Lua script.
Also add _editor.lua to ignorelist to make script context more
useful when using vim.cmd().
Problem:
luv callback `vim.uv.new_timer():start(0, 0, function() error() end)`
causes SIGSEGV, since `xstrdup` gets NULL from `lua_tostring`.
Similar to: a5b1b83a26
Solution:
Check NULL before `xstrdup`.
Problem:
When running an initial parse, parse() returns an empty table rather
than an actual range. In `languagetree.lua`, we manually check if
a parse was incremental to determine the changed parse region.
Solution:
- Always return a range (in the C side) from parse().
- Simplify the language tree code a bit.
- Logger no longer shows empty ranges on the initial parse.
Problem: nlua_call_ref_ctx() does not pop the return value in fast
context that did not error.
Solution: Fall through to end; calling nlua_call_pop_retval().
Problem:
Calling `xstrdup` with a NULL pointer causes a SIGSEGV if `lua_tostring` returns
NULL in `nlua_luv_thread_common_cfpcall`.
Crash stack trace:
- `_platform_strlen` → `xstrdup` (memory.c:469)
- `nlua_luv_thread_common_cfpcall` (executor.c:281)
Solution:
Check if `lua_tostring` returns NULL and pass NULL to `event_create` to avoid the crash.
**Problem:** Parsing can be slow for large files, and it is a blocking
operation which can be disruptive and annoying.
**Solution:** Provide a function for asynchronous parsing, which accepts
a callback to be run after parsing completes.
Co-authored-by: Lewis Russell <lewis6991@gmail.com>
Co-authored-by: Luuk van Baal <luukvbaal@gmail.com>
Co-authored-by: VanaIgr <vanaigranov@gmail.com>
Problem: We want to deprecate `nvim_err_write(ln)()` but there is no
obvious replacement (from Lua). Meanwhile we already have
`nvim_echo()` with an `opts` argument.
Solution: Add `err` argument to `nvim_echo()` that directly maps to
`:echoerr`.
Regression from 2a7d0ed614, which removed
header that is only needed if wasmtime support is enabled. Prevent this
from happening again by wrapping the include in a `HAVE_WASMTIME` check.
