| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
API append, prepend, and remove operations reach the option setter as
full replacements. This can clear an expression's untrusted flag and
allow it to write files, unlike equivalent :set operations.
Solution:
Pass replacement status through the option setters so merges preserve
the existing value's trust restrictions.
AI-assisted
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: Option validators and setters repeatedly pass error buffers and
their sizes separately. Some setters return messages in static storage.
Solution:
- Add CharBuf for borrowed writable storage, with its length including
space for a terminating NUL.
- Move option error buffers to the callers that report errors. Preserve
existing buffer sizes, truncation, and calls that do not need a
message.
- Consolidate option error formatting and the duplicated code that lists
valid option values.
- Return error messages directly from do_one_set_option().
- Remove unused arguments from get_option_newval() and
set_option_value_for().
- Handle legacy TTY assignments in the existing callers and remove the
redundant compatibility wrapper.
- Reuse CharBuf for Tree-sitter query errors.
- Pass CharBuf through the statusline and statuscolumn builders,
retaining the buffer sizes provided by their callers, including title
formatting.
AI-assisted
|
| |
|
|
|
| |
- "obj" refers to structured (non-scalar `Object`) option values.
- "optval" generally refers to the internal scalar (legacy ":set"-style)
option value.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
The object subsystem has an intermediate representation for no real
reason. Besides the code cost, this also adds an extra (api <=> OptVal)
conversion step, which is a (small) perf cost.
Solution:
We already have `Object`, so use it instead.
- drop `OptVal`, `OptValData`, `OptValType`, and related boilerplate.
- add `kObjectTypeUnset`.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ref #6645
Problem:
When a window is resized it takes space from the window right/below first,
and only falls back to the window left/above when there is no more room.
Sometimes a user wants the space to come from a specific direction.
Solution:
Add nvim_win_resize(win, width, height, {anchor}) which resizes a window
with a choosable anchor edge, letting a window grow leftwards or upwards
by taking space from the window to the left or above first. The default
anchor reproduces nvim_win_set_width()/nvim_win_set_height().
|
| |
|
|
|
|
|
|
|
|
| |
Problem:
Literal tab (or other control char) in a float title/footer is
not made printable, so it renders incorrectly instead of as "^I".
Solution:
Normalize title/footer text for display like 'statusline'
tab to "^I", parameterize parse_virt_text() with untab
and recompute the width.
|
| |
|
|
|
|
|
|
| |
Problem: vim.ui_attach() callback for nvim_echo() call that spoofs an
internal message kind is executed in fast context.
Solution: Set msg_show callback |api-fast| context dynamically at
external message callsites, and for internal list_cmd",
"progress" and "shell*" messages.
|
| |
|
|
|
|
|
|
|
|
| |
Problem: More code can be moved to evalvars.c.
Solution: Move code to where it fits better. (Yegappan Lakshmanan,
closes vim/vim#4883)
https://github.com/vim/vim/commit/da6c03342117fb7f4a8110bd9e8627b612a05a64
Co-authored-by: Bram Moolenaar <Bram@vim.org>
|
| |
|
|
|
|
|
|
|
| |
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:
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: `get_option_value` returns caller owned `Object`s but the
corresponding C apis do not marked `FUNC_API_RET_ALLOC` properly.
Solution: add `FUNC_API_RET_ALLOC` to the C apis.
|
| |
|
|
|
|
|
| |
This was kept for a while as it was a useful short hand and initially
matched what highlights what actually properly implemented. But now
|vim.hl.range()| is a better high-level shorthand with full support for
native multi-line ranges.
|
| |
|
|
|
|
|
|
|
|
| |
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:
Deprecated API `nvim_get_option()` doesn't validate the option name,
which leads to an assertion failure.
Solution:
Validate option name in `nvim_get_option()`.
Ref: #31894
|
| | |
|
| |
|
| |
Result of `make iwyu` (after some "fixups").
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
- nvim_subscribe, nvim_unsubscribe were deprecated in
aec4938a21a02d279d13a9eb64ef3b7cc592c374 but this wasn't set in the
API metadata.
- The function annotations
```
FUNC_API_SINCE(1) FUNC_API_REMOTE_ONLY FUNC_API_DEPRECATED_SINCE(13)
```
cause this test to fail:
```
RUN T3 api metadata functions are compatible with old metadata or have new level: 3.00 ms ERR
test/functional/api/version_spec.lua:135: function vim_subscribe was removed but exists in level 0 which nvim should be compatible with
stack traceback:
test/functional/api/version_spec.lua:135: in function <test/functional/api/version_spec.lua:128>
```
Solution:
- Set the API metadata.
- Rearrange the annotations so that FUNC_API_DEPRECATED_SINCE is 2nd:
```
FUNC_API_SINCE(1) FUNC_API_DEPRECATED_SINCE(13) FUNC_API_REMOTE_ONLY
```
|
| |
|
|
|
|
|
|
|
|
| |
Problem: The name `scope` is often used to refer to option flags because
`OPT_LOCAL` and `OPT_GLOBAL` are often used to determine the option
scope. This leads to the name `req_scope` being used for actual option
scopes instead.
Solution: Since the end-goal is to remove `OPT_LOCAL` and `OPT_GLOBAL`
entirely and replace them with `OptScope`, rename `OptScope` variables
to `scope` and the old scope flag variables to `opt_flags`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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:
There are three different ways of marking an option as hidden, `enable_if
= false`, `hidden = true` and `immutable = true`. These also have different
behaviors. Options hidden with `enable_if = false` can't have their value
fetched using Vim script or the API, but options hidden with `hidden = true` or
`immutable = true` can. On the other hand, options with `hidden = true` do not
error when trying to set their value, but options with `immutable = true` do.
Solution:
Remove `enable_if = false`, remove the `hidden` property for options, and use
`immutable = true` to mark an option as hidden instead. Also make hidden option
variable pointers always point to the default value, which allows fetching the
value of every hidden option using Vim script and the API. This does also mean
that trying to set a hidden option will now give an error instead of just being
ignored.
|
| |
|
|
|
|
| |
Problem: `get_option_value_for` can perfectly replace `get_option_value_strict`, making the latter redundant.
Solution: Remove `get_option_value_strict`
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
ref https://github.com/neovim/neovim/pull/28432
ref https://github.com/neovim/neovim/issues/28469
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
`vim.rpcnotify(0)` and `rpcnotify(0)` are documented as follows:
If {channel} is 0, the event is broadcast to all channels.
But that's not actually true. Channels must call `nvim_subscribe` to
receive "broadcast" events, so it's actually "multicast".
- Assuming there is a use-case for "broadcast", the current model adds
an extra step for broadcasting: all channels need to "subscribe".
- The presence of `nvim_subscribe` is a source of confusion for users,
because its name implies something more generally useful than what it
does.
Presumably the use-case of `nvim_subscribe` is to avoid "noise" on RPC
channels not expected a broadcast notification, and potentially an error
if the channel client reports an unknown event.
Solution:
- Deprecate `nvim_subscribe`/`nvim_unsubscribe`.
- If applications want to multicast, they can keep their own multicast
list. Or they can use `nvim_list_chans()` and `nvim_get_chan_info()`
to enumerate and filter the clients they want to target.
- Always send "broadcast" events to ALL channels. Don't require channels
to "subscribe" to receive broadcasts. This matches the documented
behavior of `rpcnotify()`.
|
| |
|
|
|
|
| |
TODO:
FUNC_API_REMOTE_ONLY APIs such as `nvim_ui_*` cannot (yet) be used in
`nvim_exec_lua`. We can change FUNC_API_REMOTE_ONLY to allow
Vimscript/Lua to pass an explicit `channel_id`. #28437
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
The documentation flow (`gen_vimdoc.py`) has several issues:
- it's not very versatile
- depends on doxygen
- doesn't work well with Lua code as it requires an awkward filter script to convert it into pseudo-C.
- The intermediate XML files and filters makes it too much like a rube goldberg machine.
Solution:
Re-implement the flow using Lua, LPEG and treesitter.
- `gen_vimdoc.py` is now replaced with `gen_vimdoc.lua` and replicates a portion of the logic.
- `lua2dox.lua` is gone!
- No more XML files.
- Doxygen is now longer used and instead we now use:
- LPEG for comment parsing (see `scripts/luacats_grammar.lua` and `scripts/cdoc_grammar.lua`).
- LPEG for C parsing (see `scripts/cdoc_parser.lua`)
- Lua patterns for Lua parsing (see `scripts/luacats_parser.lua`).
- Treesitter for Markdown parsing (see `scripts/text_utils.lua`).
- The generated `runtime/doc/*.mpack` files have been removed.
- `scripts/gen_eval_files.lua` now instead uses `scripts/cdoc_parser.lua` directly.
- Text wrapping is implemented in `scripts/text_utils.lua` and appears to produce more consistent results (the main contributer to the diff of this change).
|
| |
|
|
| |
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
|
| |
|
|
|
|
|
|
|
| |
As only a few API functions make use of explicit freeing of the return
value, make it opt-in instead. The arena is always present under the
hood, so `Arena *arena` arg now doesn't mean anything other than getting
access to this arena. Also it is in principle possible to return an
allocated value while still using the arena as scratch space for other
stuff (unlikely, but there no reason to not allow it).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The way ml_replace_buf is implemented makes it unfriendly for
being used in a loop: every call allocates a scratch buffer for putting
the line into the "dirty" state. This then immediately needs to be freed
as the next ml_replace_buf and/or ml_append_buf call will flush that buffer.
It's better to later pay the price of allocating the scratch buffer only if
the line is being immediately edited (likely when using the API to only
change one line) with an extra memcpy, than allocating that buffer
multiple times every time the API is called.
Of course, a separate xmalloc/xfree cycle for each time the dirty line
changes is unwanted to begin with. But fixing that is a later refactor.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Note: this contains two _temporary_ changes which can be reverted
once the Arena vs no-Arena distinction in API wrappers has been removed.
Both nlua_push_Object and object_to_vim_take_luaref() has been changed
to take the object argument as a pointer. This is not going to be
necessary once these are only used with arena (or not at all) allocated
Objects.
The object_to_vim() variant which leaves luaref untouched might need to
stay for a little longer.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
and for return value of nlua_exec/nlua_call_ref, as this uses
the same family of functions.
NB: the handling of luaref:s is a bit of a mess.
add api_luarefs_free_XX functions as a stop-gap as refactoring
luarefs is a can of worms for another PR:s.
as a minor feature/bug-fix, nvim_buf_call and nvim_win_call now preserves
arbitrary return values.
|
| |
|
|
|
| |
Refactor some earlier "temporary Array" code in buffer_updates.c to use
the modern style of MAXSIZE_TEMP_ARRAY and ADD_C
|
| | |
|
| |
|
|
|
|
| |
Remove `export` pramgas from defs headers as it causes IWYU to believe
that the definitions from the defs headers comes from main header, which
is not what we really want.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Problem:
`findoption()` searches through the options[] table linearly for option
names, even though hashy can be used to generate a compile-time hash
table for it.
Solution:
Use hashy to generate a compile time hash table for finding options.
This also allows handling option aliases, so we don't need separate
options[] table entries for things like 'viminfo'.
|
| | |
|
| |
|
|
|
|
| |
Problem: Many places in the code use `findoption()` to access an option using its name, even if the option index is available. This is very slow because it requires looping through the options array over and over.
Solution: Use option index instead of name wherever possible. Also introduce an `OptIndex` enum which contains the index for every option as enum constants, this eliminates the need to pass static option names as strings.
|
| | |
|
| |
|
|
|
|
| |
FUNC_ATTR_* should only be used in .c files with generated headers.
Defining FUNC_ATTR_* as empty in headers causes misuses of them to be
silently ignored. Instead don't define them by default, and only define
them as empty after a .c file has included its generated header.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Create mapping to most of the C spec and some POSIX specific functions.
This is more robust than relying files shipped with IWYU.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove the monolithic Decoration struct. Before this change, each extmark
could either represent just a hl_id + priority value as a inline
decoration, or it would take a pointer to this monolitic 112 byte struct
which has to be allocated.
This change separates the decorations into two pieces: DecorSignHighlight
for signs, highlights and simple set-flag decorations (like spell,
ui-watched), and DecorVirtText for virtual text and lines.
The main separation here is whether they are expected to allocate more
memory. Currently this is not really true as sign text has to be an
allocated string, but the plan is to get rid of this eventually (it can
just be an array of two schar_T:s). Further refactors are expected to
improve the representation of each decoration kind individually. The
goal of this particular PR is to get things started by cutting the
Gordian knot which was the monolithic struct Decoration.
Now, each extmark can either contain chained indicies/pointers to
these kinds of objects, or it can fit a subset of DecorSignHighlight
inline.
The point of this change is not only to make decorations smaller in
memory. In fact, the main motivation is to later allow them to grow
_larger_, but on a dynamic, on demand fashion. As a simple example, it
would be possible to augment highlights to take a list of multiple
`hl_group`:s, which then would trivially map to a chain of multiple
DecorSignHighlight entries.
One small feature improvement included with this refactor itself, is
that the restriction that extmarks cannot be removed inside a decoration
provider has been lifted. These are instead safely lifetime extended
on a "to free" list until the current iteration of screen drawing is done.
NB: flags is a mess. but DecorLevel is useless, this slightly less so
|
