Problem:
Remote UIs can't execute lua code when a blocking prompt is waiting for
input. This is needed when implementing IME pre-edit for example.
Solution:
Add an `nvim__exec_lua_fast` experimental API function, which is allowed
to run instead of being queued until after the message has been shown.
Problem:
Calling `:restart` twice erases the original args passed to `nvim`. This
is caused by interactions between the `:restart` command handler, the
`v:argv` parsing logic in the UI restart handler, and the options added
to `v:argv` by the server upon restart.
For example,
* Launch `nvim` as `nvim foo`:
* initial argv: `nvim foo`
* after nvim server launch: `nvim --embed foo`
* Run `:restart`
* after `ex_restart()`: `nvim -c '' --embed foo`
* after `remote_ui_restart()`: `nvim -c '' foo`
* after nvim server launch: `nvim --embed -c '' foo`
* Run `:restart` again
* after `ex_restart()`: `nvim -c '' --embed -c '' foo`
* after `remote_ui_restart()`: `nvim -c ''`
* after nvim server launch: `nvim --embed -c ''`
The intention of the argv parser in `remote_ui_restart()` is to only
take the first `-c cmd` and ignore any additional ones, but it actually
ignores the rest of argv when it encounters a second `-c` and there are
no `-` or `--` remaining.
Solution:
Fix the argv parser to reset the `skipping_minc` flag at the end of
every iteration that does not reach the `continue` statement.
Problem: Cannot reuse same config with noautocmd for both window
creation and updates, even when value is unchanged.
Solution: Only reject noautocmd changes for existing windows.
The processing of terminfo can be separated into two steps:
1. The initialization of terminfo, which includes trying to find $TERM
in a terminfo database file. As a fallback, common terminfo
definitions are compiled in. After this, we apply a lot of ad-hoc
patching to cover over limitations of terminfo.
2. While processing updates from nvim, actually using terminfo strings
and formatting them with runtime values. for this part, terminfo
essentially is a hyper-enhanced version of snprintf(), including
a sm0l stack based virtual machine which can manipulate the runtime
parameters.
This PR completely replaces libuniblium for step 2, with code
vendored from NetBSD's libtermkey which has been adapted to use typesafe
input parameters and to write into an output buffer in place.
The most immedatiate effects is a performance enhancement of
update_attrs() which is a very hot function when profiling the
TUI-process part of screen updates. In a stupid microbenchmark
(essentially calling nvim__screenshot over and over in a loop) this
leads to a speedup of ca 1.5x for redrawing the screen on the TUI-side.
What this means in practise when using nvim as a text editor is probably
no noticible effect at all, and when reabusing nvim as idk a full screen
RGB ASCII art rendrer maybe an increase from 72 to 75 FPS LMAO.
As nice side-effect, reduce the usage of unibilium to initialization only..
which will make it easier to remove, replace or make unibilium optional,
adressing #31989. Specifically, the builtin fallback doesn't use
unibilium at all, so a unibilium-free build is in principle possible
if the builtin definitions are good enough.
As a caveat, this PR doesn't touch libtermkey at all, which still has a
conditional dependency on unibilium. This will be investigated in a
follow-up PR
Note: the check of $TERMCOLOR was moved from tui/tui.c to
_defaults.lua in d7651b27d5 as we want to
skip the logic in _defaults.lua if the env var was set, but there
is no harm in TUI getting the right value when the TUI is trying to
initialize its terminfo shenanigans. Also this check is needed when
a TUI connects to a `--headless` server later, which will observe
a different $TERMCOLOR value than the nvim core process itself.
Problem:
1. Setting `pumborder=+,+,+,+,+,+,+,+` failed to render the custom
border characters correctly. The issue occurred in `parse_winborder()`
where it incorrectly used `p_winborder` instead of the `border_opt`
parameter when the option value didn't contain commas.
2. In `pum_redraw()`, calling `parse_border_style()` directly with the
option string failed to parse comma-separated border characters.
3. Missing documentation for PmenuShadow and PmenuShadowThrough
highlight groups used by the shadow border style.
4. Coverity reports CID 631420: passing WinConfig (480 bytes) by value
in `grid_draw_border()`.
5. crash when using `shadow` value on pumborder.
Solution:
1. Fix `parse_winborder()` to use `border_opt` parameter consistently,
ensuring the correct option value is parsed regardless of which
option (winborder/pumborder) is being set.
2. Update `pum_redraw()` to call `parse_winborder()` instead of
`parse_border_style()`, properly handling both predefined styles
and custom comma-separated border characters.
3. Add documentation for PmenuShadow (blended shadow areas) and
PmenuShadowThrough (see-through corners) highlight groups.
4. Change `grid_draw_border()` to accept WinConfig by pointer.
5. When the "shadow" style is used, no additional row and column offset
is applied, and the border width is reduced.
Problem:
Popup menu cannot have a border.
Solution:
Support 'pumborder' option.
Generalize `win_redr_border` to `grid_redr_border`,
which redraws border for window grid and pum grid.
Problem: after #35601, nvim_open_win incorrectly attempts to set the size of a
split window to 0 if it wasn't specified.
Solution: only attempt to set the size again if it was actually specified. This has the effect of defaulting to half the size of the parent window (or it may be equalized with other windows to make room), like before.
Fix#36080
Problem: More code can be moved to evalvars.c.
Solution: Move code to where it fits better. (Yegappan Lakshmanan,
closesvim/vim#4883)
da6c033421
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: requested window size passed to nvim_open_win for splits may be ignored
by win_split_ins if it decides to forcefully equalize window sizes instead (e.g:
in an attempt to make room for the new window).
Solution: try to set the size again if it differs from what was requested.
Co-authored-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
Problem: The ops.c file is too big.
Solution: Move code for dealing with registers to a new file. (Yegappan
Lakshmanan, closesvim/vim#4982)
4aea03eb87
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem:
Multigrid UIs have to find out which window to send the input by using
the Nvim focus rules, which are not fully documented.
Furthermore,`getmousepos()` has several problems when multigrid is
enabled, with the main one being that screenrow and screencol are window
relative instead of screen relative, due to the fact that the UI don't
send any absolute coordinates.
Solution:
Allow passing 0 as grid to `nvim_input_mouse`, with absolute
coordinates, which lets nvim determine the actual window to send the
mouse input to. This works as long as nvim is in charge of the window
positioning. If the UI repositions or resizes the windows, it can still
pass the grid it determines like before.
Problem: A 'rulerformat' not part of the statusline is not emitted through
msg_ruler events.
Solution: Build the message chunks to emit as a msg_ruler event.
This partially reverts 0b8a72b739,
that is unreverts 15e77a56b7
"priority" is an internal neovim concept which does not occur in shared
queries. Ideally a single priority space should eventually be enough
for our needs. But as we don't want to poke at the usages of
priorities right now in the wider ecosystem,
introduce the "subpriorities" so that treesitter code can distinguish
highlights of the same priorities with different tree nesting depth.
This mainly affects `injection.combined` as parent-tree nodes might appear
in the middle of child-tree nodes which otherwise is not possible.
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: nvim_win_set_config may crash when attempting to move curwin to a
different tabpage if there is no other non-float available to switch to.
Solution: fix the crash. Fix ONE_WINDOW checks in winframe_find_altwin and
win_altframe to consider floating windows by instead using one_window. Allow
one_window to consider non-current tabpages. We can use one_window in
win_close_othertab now to also better reflect its use in win_close.
Co-authored-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
Problem: w_pos_changed flag was being set redundantly after win_config_float call
Solution: remove duplicate assignment since win_config_float already sets this flag internally
Problem: The document of nvim_buf_get_extmark currently lacks the
following:
- "details" directory: nvim_buf_get_extmarks() allows an option details
to get a "details" directory in result, but it doesn't mention where
that "details" directory is, what fields does it have.
Solution: Add docs for "details" directory in nvim_buf_get_extmarks()
Problem: after #34287 nvim_win_set_config no longer errors when attempting to
split from a floating window only if "win" is 0.
Solution: fix the regression, reduce the scope of "parent" and similar checks to
only where it's currently used and add test coverage for the errors.
Problem: `nvim_win_set_config` calls `win_find_tabpage(parent)` with redundant calls
Solution: Cache `parent_tp` early and reuse before window operations.
- Problem: It's not clear for new plugin developers that `:help` uses
a help-tags file for searching the docs, generated by `:helptags`.
- Solution: Hint to the |:helptags| docs for regenerating the tags
file for their freshly written documentation.
Co-authored-by: Yochem van Rosmalen <git@yochem.nl>
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: Decoding of mouse click escape sequence is not tested.
Solution: Add a test for xterm and SGR using low-level input. Make
low-level input execution with feedkeys() work.
905dd905de
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem:
`msg_show` has "progress" info (title, status, percent) which is not presented
by default.
Solution:
Format TUI messages as `{title}: {msg}...{percent}%`. This also gets sent to UI.
- With specific formatting sent to UI we can remove the `progress` item from
`msg_show` event. It can be added if needed in the future. Also, having
a default presentation makes the feature more useful.
- For `vim._extui` we just need to implement the replace-msg-with-same-id
behavior.
- If any UI/plugin wants to do anything fancier, they can handle the `Progress`
event.
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`.
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.
Problem: parse_cmdline() sets eap->cmdlinep to address of local parameter,
causing invalid memory access when expand_filename() tries to modify it.
This leads to crashes when typing '%' in user commands with preview=true
and complete=file.
Solution: Change parse_cmdline() signature to accept char **cmdline,
allowing cmdlinep to point to caller's variable for safe reallocation.
Problem:
Not easy for a user to tell ":restart" to "run this command(s) after restarting".
Solution:
All ":restart" args following the optional +cmd arg are treated as a big cmdline that is passed as a "-c" CLI arg when restarting nvim.
Problem: Using `addr` without `range` in nvim_create_user_command gives
"No range allowed" error, inconsistent with `:command -addr` behavior.
Solution: Set EX_RANGE flag when `addr` option is specified to match
`:command` behavior.
Problem: no check for nvim_open_win opening a new floating window into a closing
buffer, which can lead to crashes.
Solution: call check_split_disallowed; opening a new float semantically splits
from a window, so the same problems as regular splits apply. Also restore the
error if switch_win_noblock in win_set_buf fails (may not be possible to hit
this, but win_set_buf can silently succeed there since #31595).
As the lock check applies to curbuf (not the target buffer) this may feel a bit
restrictive, though this isn't different to how things like ":split" or
nvim_open_win with "split = true" works when targeting a different buffer. Only
checking the target buffer's lock will cause issues if win_set_buf doesn't end
up in the target buffer for whatever reason.
Maybe we could consider checking the lock of the buffer after win_set_buf and
close the window if it's locked (maybe a bit fiddly, especially as closing a
window can fail...), or make the open + switch operation more atomic, like how
Vim does for its popup windows..?
It also used to be the case that win_set_buf would set an error if autocommands
sent us to a different buffer than what was requested, but #31595 appears to
have also changed that... I haven't touched that here.
