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.
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()`.
- Render Lua types in api.txt.
- Added `DictAs(name)` API type which acts the same as `Dict` (no parens)
when generating the dispatchers, but acts the same as `Dict(name)`
when generating docs.
- Added `Tuple(...)` API type which is the treated the as `Array` for
generating the dispatchers, but is used to document richer types.
- Added `Enum(...)` API type to better document enums
- Improve typing of some API functions.
- Improve c_grammar to properly parse API types and replace string pattern
logic in the parsers.
- Removed all the hardcoded type overrides in gen_eval_files.lua
Problem: Unable to emit a message with arbitrary kind.
Solution: Add a "kind" opts field to nvim_echo().
Use it to set the "list_cmd" kind for vim.show_pos().
Problem:
Descriptions are somewhat vague. nvim_set_current_line modifies contents
but nvim_set_current_buf does not, etc.
Solution:
- Make it clear that these functions accept or return a winid/tabid by
linking to that concept in help.
- Only these few files use the term "handles", so replace them with the
more conventional terminology.
- Add a new help section for tab-ID. This concept is unique to neovim
because vim exposes tabnr, but not tab handles. This section is
modelled after `:h winid`.
Problem: Combined highlighting was not applied to nvim_eval_statusline(),
and 'statuscolumn' sign segment/numhl highlights.
Solution: Add an additional `groups` element to the return value of
`nvim_eval_statusline()->highlights`. This is an array of stacked
highlight groups (highest priority last). Also resolve combined
highlights for the 'statuscolumn' sign segment/numhl highlights.
Expose/synchronize some drawline.c logic that is now mimicked in
three different places.
Problem:
The `nvim_notify` API (note: unrelated to `vim.notify()` Lua API) was
not given any real motivation in https://github.com/neovim/neovim/pull/13843
There are, and were, idiomatic and ergonomic alternatives already.
Solution:
Deprecate `nvim_notify`.
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`.
Problem:
If completeopt does not include "popup" flag, nvim__complete_set still
auto-creates a floating preview window.
Solution:
Fail if completeopt does not include the "popup" flag.
Problem:
`nvim__redraw()` doesn't clamp the lines in the `range` parameter before truncating to int. The resulting range may be empty when the original range contained buffer lines and vice versa.
E.g. for a buffer with 4 lines, these are the redrawn lines:
```lua
{ 2, 2 ^ 31 } -> none (should be { 2, 3 })
{ 2, 2 ^ 32 } -> none (should be { 2, 3 })
{ 2 ^ 32 - 1, 2 } -> { 0, 1 } (should be none)
```
Solution:
Clamp `range` values before truncating to int.
Problem: Two separate try/end wrappers, that only marginally differ by
restoring a few variables. Wrappers that don't restore
previous state are dangerous to use in "api-fast" functions.
Solution: Remove wrappers that don't restore the previous state.
Always use TRY_WRAP.
Problem:
- API functions using `try_start` directly, do not surface the
underlying error message, and instead show generic messages.
- Error-handling code is duplicated in the API impl.
- Failure modes are not tested.
Solution:
- Use `TRY_WRAP`.
- Add tests.
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.
Problem: Option metadata like list of valid values for an option and
option flags are not listed in the `options.lua` file and are instead
manually defined in C, which means option metadata is split between
several places.
Solution: Put metadata such as list of valid values for an option and
option flags in `options.lua`, and autogenerate the corresponding C
variables and enums.
Supersedes #28659
Co-authored-by: glepnir <glephunter@gmail.com>
Problem: Not possible to only set a "redraw later" type with
nvim__redraw, which seems to be desired for the
treesitter highlighter.
Solution: Do not update the screen when "flush" is explicitly set to
false and only redraw later types are present. In that case,
do not call ui_flush() either.
Problem: nvim__redraw's "range" marks a buffer range for redraw, and subsequently
flushes the UI without updating the windows containing that buffer.
Solution: Implicitly update the screen, unless specified otherwise.
Only update the screen with the last call of the treesitter
on_changedtree() callback.
Problem: Documentation for "hl_group" in nvim_buf_set_extmark() is
unclear. "hl_group" in nvim_echo() does not accept
highlight group id.
Solution: Move documentation for highlight group name/id to first
mention of hl_group. Update nvim_echo() to accept highlight
group id.
Problem:
The way option scopes currently work is inflexible and does not allow for nested
option scopes or easily finding the value of an option at any arbitrary scope
without having to do long handwritten switch-case statements like in
`get_varp()`. `.indir` is also confusing and redundant since option indices for
each scope can be autogenerated.
Solution:
Expand option scopes in such a way that an option can support any amount of
scopes using a set of scope flags, similarly to how it's already done for option
types. Also make options contain information about its index at each scope it
supports. This allows for massively simplifying `get_varp()` and
`get_varp_scope()` in the future by just using a struct for options at each
scope. This would be done by creating a table that stores the offset of an
option's variable at a scope by using the option's index at that scope as a key.
This PR also autogenerates enums for option indices at each scope to remove the
need for `.indir` entirely, and also to allow easily iterating over options all
options that support any scope.
Ref: #29314
Problem: Lua callbacks for "msg_show" events with vim.ui_attach() are
executed when it is not safe.
Solution: Disallow non-fast API calls for "msg_show" event callbacks.
Automatically detach callback after excessive errors.
Make sure fast APIs do not modify Nvim state.
Problem: Highlight group id is not propagated to the end of the message call
stack, where ext_messages are emitted.
Solution: Refactor message functions to pass along highlight group id
instead of attr id.
Problem: too many strlen() calls in register.c
Solution: refactor code, add string_T struct to keep track
of string lengths (John Marriott)
closes: vim/vim#1595279f6ffd388
Co-authored-by: John Marriott <basilisk@internode.on.net>
Problem: When using nvim_paste in a mapping during a macro recording,
both the mapping and the paste are recorded, causing the paste
to be performed twice when replaying the macro.
Solution: Only record a paste when it is from RPC.
Unfortunately this means there is no way for a script to make a recorded
paste. A way to enable that can be discussed later if there is need.
Before this PR, the behavior of nvim_paste is:
- When vim.paste() returns false, return false to the client, but treat
following chunks normally (i.e. rely on the client cancelling the
paste as expected).
- When vim.paste() throws an error, still return true to the client, but
drain the following chunks in the stream without calling vim.paste().
There are two problems with such behavior:
- When vim.paste() errors, the client is still supposed to send the
remaining chunks of the stream, even though they do nothing.
- Having different code paths for two uncommon but similar situations
complicates maintenance.
This PR makes both the cancel case and the error case return false to
the client and drain the remaining chunks of the stream, which, apart
from sharing the same code path, is beneficial whether the client checks
the return value of nvim_paste or not:
- If the client checks the return value, it can avoid sending the
following chunks needlessly after an error.
- If the client doesn't check the return value, chunks following a
cancelled chunk won't be pasted on the server regardless, which leads
to less confusing behavior.
In the api_info() output:
:new|put =map(filter(api_info().functions, '!has_key(v:val,''deprecated_since'')'), 'v:val')
...
{'return_type': 'ArrayOf(Integer, 2)', 'name': 'nvim_win_get_position', 'method': v:true, 'parameters': [['Window', 'window']], 'since': 1}
The `ArrayOf(Integer, 2)` return type didn't break clients when we added
it, which is evidence that clients don't use the `return_type` field,
thus renaming Dictionary => Dict in api_info() is not (in practice)
a breaking change.
- Fixes 'autoindent' being applied during redo.
- Makes redoing a large paste significantly faster.
- Stores pasted text in the register being recorded.
Fix#28561
Problem:
The default builtin UI client does not declare its client info. This
reduces discoverability and makes it difficult for plugins to identify
the UI.
Solution:
- Call nvim_set_client_info after attaching, as recommended by `:help dev-ui`.
- Also set the "pid" field.
- Also change `ui_active()` to return a count. Not directly relevant to
this commit, but will be useful later.
Problem:
- "process" is often used as a verb (`multiqueue_process_events`), which
is ambiguous for cases where it's used as a topic.
- The documented naming convention for processes is "proc".
- `:help dev-name-common`
- Shorter is better, when it doesn't harm readability or
discoverability.
Solution:
Rename "process" => "proc" in all C symbols and module names.
