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>
Problem: there is missing default title highlight when highlight not defined in title text chunk.
Solution: when attr is not set use default title highlight group.
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()`.
Problem:
The nvim_win_xx_ns function family introduced in ba0370b1d7
needs more bake-time. Currently it's narrowly defined for windows, but
other scopes ("buffer") and features are likely in the future.
Solution:
- Rename the API with double-underscore to mark it as EXPERIMENTAL.
TODO/FUTURE:
- Rename and change the signature to support more than just "window"
scope, and for other flexibility.
- Open question: we could choose either:
- "store scopes on namespaces", or
- "store namespaces on scopes (w:/b:/…)"
Experimental and subject to future changes.
Add a way to redraw certain elements that are not redrawn while Nvim is waiting
for input, or currently have no API to do so. This API covers all that can be
done with the :redraw* commands, in addition to the following new features:
- Immediately move the cursor to a (non-current) window.
- Target a specific window or buffer to mark for redraw.
- Mark a buffer range for redraw (replaces nvim__buf_redraw_range()).
- Redraw the 'statuscolumn'.
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: noautocmd is confusing; despite its name, it doesn't block all
autocommands (instead it blocks only those related to setting the buffer), and
is commonly used by plugins to open windows while producing minimal
side-effects.
Solution: be consistent and block all autocommands when noautocmd is set.
This includes WinNew (again), plus autocommands from entering the window (if
enter is set) like WinEnter, WinLeave, TabEnter, .etc.
See the discussion at https://github.com/neovim/neovim/pull/14659#issuecomment-2040029517
for more information.
Remove win_set_buf's noautocmd argument, as it's no longer needed.
NOTE: pum_create_float_preview sets noautocmd for win_set_buf, but all its
callers already use block_autocmds.
Despite that, pum_create_float_preview doesn't actually properly handle
autocommands (it has no checks for whether those from win_enter or
nvim_create_buf free the window).
For now, ensure autocommands are blocked within it for correctness (in case it's
ever called outside of a block_autocmds context; the function seems to have been
refactored in #26739 anyway).
Problem: nvim_open_win blocking all win_set_buf autocommands when !enter &&
!noautocmd is too aggressive.
Solution: temporarily block WinEnter/Leave and BufEnter/Leave events when
setting the buffer. Delegate the firing of BufWinEnter back to win_set_buf,
which also has the advantage of keeping the timing consistent (e.g: before the
epilogue in enter_buffer, which also handles restoring the cursor position if
autocommands didn't change it, among other things). Reword the documentation for
noautocmd a bit.
I pondered modifying do_buffer and callees to allow for BufEnter/Leave being
conditionally disabled, but it seems too invasive (and potentially error-prone,
especially if new code paths to BufEnter/Leave are added in the future).
Unfortunately, doing this has the drawback of blocking ALL such events for the
duration, which also means blocking unrelated such events; like if window
switching occurs in a ++nested autocmd fired by win_set_buf. If this turns out
to be a problem in practice, a different solution specialized for nvim_open_win
could be considered. :-)
Problem: currently, for splits, nvim_win_set_config accepts win without any of
split or vertical set, which has little effect and seems error-prone.
Solution: require at least one of split or vertical to also be set for splits.
Also, update nvim_win_set_config docs, as it's no longer limited to just
floating and external windows.
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).
To align the output of `nvim_get_hl` with its documentation -- which
points to `nvim_set_hl`, remove mentions of the keys `foreground`,
`background` and `special`.
The long keys are are still supported (via fallback checks inside
`dict2hlattrs`), but the `fg`, `bg` and `sp` keys are preferenced.
https://github.com/neovim/neovim/pull/27428 changed the semantics of
callbacks passed to nvim_create_autocmd such that any truthy value will
delete the autocommand (rather than just the literal boolean value
`true`). Update the documentation accordingly and add an entry to
`news.txt`.
The behavior is now consistent between nvim_create_autocmd and
nvim_buf_attach.
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.
Getting current channel info was kind of annoying via RPC. Two
functions had to be called:
1. `nvim_get_api_info` which returns `[channel_id, meta_data]`.
- This results in `channel_id = api.nvim_get_api_info()[0]`.
- Here the meta_data is sent but never used.
2. Finally call `nvim_get_chan_info(channel_id)`.
This commit reduces the need for `nvim_get_api_info` as passing 0
returns current channel info.
Extmarks can contain URLs which can then be drawn in any supporting UI.
In the TUI, for example, URLs are "drawn" by emitting the OSC 8 control
sequence to the TTY. On terminals which support the OSC 8 sequence this
will create clickable hyperlinks.
URLs are treated as inline highlights in the decoration subsystem, so
are included in the `DecorSignHighlight` structure. However, unlike
other inline highlights they use allocated memory which must be freed,
so they set the `ext` flag in `DecorInline` so that their lifetimes are
managed along with other allocated memory like virtual text.
The decoration subsystem then adds the URLs as a new highlight
attribute. The highlight subsystem maintains a set of unique URLs to
avoid duplicating allocations for the same string. To attach a URL to an
existing highlight attribute we call `hl_add_url` which finds the URL in
the set (allocating and adding it if it does not exist) and sets the
`url` highlight attribute to the index of the URL in the set (using an
index helps keep the size of the `HlAttrs` struct small).
This has the potential to lead to an increase in highlight attributes
if a URL is used over a range that contains many different highlight
attributes, because now each existing attribute must be combined with
the URL. In practice, however, URLs typically span a range containing a
single highlight (e.g. link text in Markdown), so this is likely just a
pathological edge case.
When a new highlight attribute is defined with a URL it is copied to all
attached UIs with the `hl_attr_define` UI event. The TUI manages its own
set of URLs (just like the highlight subsystem) to minimize allocations.
The TUI keeps track of which URL is "active" for the cell it is
printing. If no URL is active and a cell containing a URL is printed,
the opening OSC 8 sequence is emitted and that URL becomes the actively
tracked URL. If the cursor is moved while in the middle of a URL span,
we emit the terminating OSC sequence to prevent the hyperlink from
spanning multiple lines.
This does not support nested hyperlinks, but that is a rare (and,
frankly, bizarre) use case. If a valid use case for nested hyperlinks
ever presents itself we can address that issue then.
Problem: Some lines in the generated vim doc are overflowing, not
correctly wrapped at 78 characters. This happens when docs body contains
several consecutive 'inline' elements generated by doxygen.
Solution: Take into account the current column offset of the last line,
and prepend some padding before doc_wrap().
Problem:
Many decoration providers (treesitter injection highlighting, semantic
token highlighting, inlay hint) rely on the correctness of the `botline`
argument of `on_win` callback. However, `botline` can be smaller than
the actual line number of the last displayed line if some lines are
folded. In such cases, some decorations will be missing in the lines not
covered by `botline`.
Solution:
Validate `botline` when invoking `on_win`.
NOTE:
It seems that the old code was deliberately avoiding this presumably due
to performance reasons. However, I haven't experienced noticeable lag
after this change, and I believe the cost of botline computation would
be much smaller than the cost of decoration providers.
Problem: Unable to predict which byte-offset to place virtual text to
make it repeat visually in the wrapped part of a line.
Solution: Add a flag to nvim_buf_set_extmark() that causes virtual
text to repeat in wrapped lines.
Problem:
Unlike termopen(), nvim_open_term() PTYs do not carriage-return the
cursor on newline ("\n") input.
nvim --clean
:let chan_id = nvim_open_term(1, {})
:call chansend(chan_id, ["here", "are", "some", "lines"])
Actual behavior:
here
are
some
lines
Expected behaviour:
here
are
some
lines
Solution:
Add `force_crlf` option, and enable it by default.
decor->text.str pointer must go. This removes it for conceal char,
in preparation for a larger PR which will also handle the sign case.
By actually allowing composing chars for a conceal chars, this
becomes a feature and not just a refactor, as a bonus.
Problem: The legacy signlist data structures and associated functions are
redundant since the introduction of extmark signs.
Solution: Store signs defined through the legacy commands in a hashmap, placed
signs in the extmark tree. Replace signlist associated functions.
Usage of the legacy sign commands should yield no change in behavior with the
exception of:
- "orphaned signs" are now always removed when the line it is placed on is
deleted. This used to depend on the value of 'signcolumn'.
- It is no longer possible to place multiple signs with the same identifier
in a single group on multiple lines. This will now move the sign instead.
Moreover, both signs placed through the legacy sign commands and through
|nvim_buf_set_extmark()|:
- Will show up in both |sign-place| and |nvim_buf_get_extmarks()|.
- Are displayed by increasing sign identifier, left to right.
Extmark signs used to be ordered decreasingly as opposed to legacy signs.
Problem:
Platform-specific UI providers should live in `vim.ui.*`. #24164
Solution:
- Move `vim.clipboard.osc52` module to `vim.ui.clipboard.osc52`.
- TODO: move all of `clipboard.vim` to `vim.ui.clipboard`.
ref #25872
Problem: No way to have extmarks automatically removed when the range it
is attached to is deleted.
Solution: Add new 'invalidate' property that will hide a mark when the
entirety of its range is deleted. When "undo_restore" is set
to false, delete the mark from the buffer instead.
When the terminal emulator sends an OSC sequence to Nvim (as a response
to another OSC sequence that was first sent by Nvim), populate the OSC
sequence in the v:termresponse variable and fire the TermResponse event.
The escape sequence is also included in the "data" field of the
autocommand callback when the autocommand is defined in Lua.
This makes use of the already documented but unimplemented TermResponse
event. This event exists in Vim but is only fired when Vim receives a
primary device attributes response.
Fixes: https://github.com/neovim/neovim/issues/25856
