| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
| |
Problem: In an autocommand Lua callback whether `args.file` is expanded
depends on whether `expand('<afile>')` has been called.
Solution: Always use the unexpanded file name for `args.file`.
Related to #31306 and vim/vim#16106. This doesn't provide `sfname`, but
at least makes `args.file` have a consistent value.
|
|
|
|
|
|
|
|
|
|
| |
Problem:
Various keywords are commonly searched-for on https://neovim.io, but
don't have help tags.
Solution:
Add help tags.
fix #31327
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: 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:
`validate_option_value_args()` returns `OK` even if option name is
invalid or if option doesn't have the supported scope, which leads to
Neovim still trying to erroneously get/set the option in those cases,
which can lead to an assertion failure when `option_has_scope()` is
invoked. This issue miraculously doesn't exist in release builds since
the assertion is skipped and `(get/set)_option_value_for` returns if
there is an error set, but that is not the intended location for that
error to be caught.
Solution:
Make `validate_option_value_args()` return `FAIL` if there is an error
set, which causes the API option functions to return early instead of
trying to get/set an invalid option.
|
| |
|
|
|
|
|
|
|
|
| |
Problem:
If there's an error in `FileType` autocmd, the filetype get-opt buffer
doesn't get cleaned up.
Solution:
Call `aucmd_restbuf`.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
| |
Fix regression from #31195
|
|
|
|
|
|
|
|
| |
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: Floating windows with focusable set to false can reasonably be
expected to be UI elements but are listed in some outputs that
should contain only regular windows.
Solution: Hide unfocusable floating windows from the default tabline and
:tabs.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This makes it possible to use HLF_ values directly as highlight id:s
and avoids +1 adjustments especially around messages.
|
|\
| |
| | |
feat(ext_messages): add hl_id to ext_messages chunks
|
| |
| |
| |
| |
| |
| |
| | |
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.
|
|/
|
|
|
|
|
| |
Co-authored-by: Ernie Rael <errael@raelity.com>
Co-authored-by: Famiu Haque <famiuhaque@proton.me>
Co-authored-by: Jade <spacey-sooty@proton.me>
Co-authored-by: glepnir <glephunter@gmail.com>
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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`
|
|
|
|
|
|
|
|
|
|
|
| |
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#15952
https://github.com/vim/vim/commit/79f6ffd388299ef3b1c95cbe658785e6e66df144
Co-authored-by: John Marriott <basilisk@internode.on.net>
|
|
|
|
| |
Problem: Cannot allow mouse interaction for non-focusable float window.
Solution: Add a "mouse" field to float window config.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Co-authored-by: Mathias Fussenegger <f.mathias@zignar.net>
Co-authored-by: Ananth Bhaskararaman <antsub@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Make utf_head_off more robust against invalid sequences
and embedded NUL chars
|
|
|
|
|
|
|
|
|
|
| |
Problem:
crash when calling nvim_buf_get_text() with a large negative start_col:
call nvim_buf_get_text(0, 0, -123456789, 0, 0, {})
Solution:
clamp start_col after subtracting it from the line length.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
704ba4151e7f67999510ee0ac19fdabb595d530c, but that was basically
a workaround for the fragility of `$NVIM_LISTEN_ADDRESS`.
|
|
|
|
|
|
|
|
|
| |
Use the grapheme break algorithm from utf8proc to support grapheme
clusters from recent unicode versions.
Handle variant selector VS16 turning some codepoints into double-width
emoji. This means we need to use ptr2cells rather than char2cells when
possible.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
This also makes shada reading slightly faster due to avoiding
some copying and allocation.
Use keysets to drive decoding of msgpack maps for shada entries.
|
|
|
|
|
|
| |
Problem: Unable to move cursor to recently opened window.
Solution: Make sure uninitialized window is drawn before trying to move
the cursor to it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Before this change, "static inline" functions in headers needed to have
their function attributes specified in a completely different way. The
prototype had to be duplicated, and REAL_FATTR_ had to be used instead
of the public FUNC_ATTR_ names.
TODO: need a check that a "header.h.inline.generated.h" file is not
forgotten when the first "static inline" function with attributes
is added to a header (they would just be silently missing).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a breaking change which will make refactor of typval and shada
code a lot easier. In particular, code that would use or check for
v:msgpack_types.binary in the wild would be broken. This appears to be
rarely used in existing plugins.
Also some cases where v:msgpack_type.string would be used to represent a
binary string of "string" type, we use a BLOB instead, which is
vimscripts native type for binary blobs, and already was used for BIN
formats when necessary.
msgpackdump(msgpackparse(data)) no longer preserves the distinction
of BIN and STR strings. This is very common behavior for
language-specific msgpack bindings. Nvim uses msgpack as a tool to
serialize its data. Nvim is not a tool to bit-perfectly manipulate
arbitrary msgpack data out in the wild.
The changed tests should indicate how behavior changes in various edge
cases.
|
|
|
|
| |
Step towords completely eliminating msgpack_packer.
|
|
|
|
|
|
| |
Co-authored-by: Ilia Choly <ilia.choly@gmail.com>
Co-authored-by: Jose Pedro Oliveira <jose.p.oliveira.oss@gmail.com>
Co-authored-by: Maria José Solano <majosolano99@gmail.com>
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
|
|
|
|
|
|
|
| |
Work towards getting rid of libmsgpack depedency eventually.
msgpack_sbuffer is just a string buffer, we can use our own
String type.
|