Why?
- Because we can.
- Because the TUI is just another GUI™
- Because it looks kinda nice, and provides useful context like 1 out of 100
times
Complies with "don't pay for what you don't use".
Some crashes for resizing were unfolded, add tests for those.
Initially we will use this for the popupmenu, floating windows will
follow soon
NB: writedelay + compositor is weird, we need more flexible
redraw introspection.
- When setting a fixed/locked/readonly var, it is more relevant to
report on the key, not its container dict. If its container dict (v:)
is readonly, that does not mean the key itself is readonly.
- Allow modifying a "fixed" var. "fixed" only prevents deletion.
There is no need to call update_screen() directly in an API function,
mode input processing invokes update_screen() as needed. And if the API
call is done in a context where redraw is disabled, then redraw is
disabled for a reason. A lot of API functions are of equal semantical
strength (nvim_call_function and nvim_execute_lua can also do whatever,
nvim_command is not special), this inconsistency has no purpose.
Namespaces is a lightweight concept that should be used to group
objects for purposes of bulk operations and introspection. This is
initially used for highlights and virtual text in buffers, and is
planned to also be used for extended marks. There is no plan use them
for privileges or isolation, neither to introduce nanespace-level
options.
msgpack_rpc_to_object (called by handle_request .. msgpack_rpc_to_array)
always NUL-terminates API Strings.
But handle_request .. msgpack_rpc_get_handler_for operates on a raw
msgpack_object, before preparation.
Previously, when neovim would wrap a line across multiple lines,
terminal emulators could not detect that the lines represent a single
wrapped line as opposed to several separate lines. As a result, many
terminals' selection/copying functionality would treat a wrapped line as
several newline-delimited lines.
Fix this by reenabling a "special trick" from Vim. When a line is
wrapped, write the last character of that line followed by the first
character of the next line to the terminal. This hints to the terminal
that the next line is a continuation of the current line.
Extends the raw_line event with a "wrap" parameter which controls when
to do wrap hinting.
Make sure cmdline updates will receive highlight specifications the same
way as screen cells. This is controlled by the ext_newgrid option so
nothing is changed by default (as screen cells are also not changed by
default). This was already done for the cmdline itself in #8221, this
extends it to cmdline_block. Which currently doesn't store highlights,
but the placeholder should be one that makes sense for future use.
