Problem: Storing the configured 'cmdheight' value is scheduled and
may happen after cmdline2_spec already entered block_mode.
Excessive wait time for expected screen state due to delayed
ruler after an error message.
Solution: Only schedule storing the user configured 'cmdheight' if
v:vim_did_enter is unset. Use regular message instead of error.
Problem: The message window is essentially a regular floating window
but does not use 'winborder'.
Still some "scratch" buffer options unset after it was removed
from its window.
Solution: Do not set the border when opening the window message.
Forego passing `scratch = true` when opening a buffer,
set the options manually when necessary.
Co-authored-by: Luuk van Baal <luukvbaal@gmail.com>
Problem: vim._extui unconditionally creates windows, buffers and the
Vimscript cmdline highlighter when it is first loaded.
Solution: Schedule first creation of the window so that first redraw
happens sooner (still need to create at least the cmdline
window asap as it can have a different highlight through
hl-MsgArea; thus further delaying until the first event that
needs a particular target seems redundant). Load the cmdline
highlighter on the first cmdline_show event.
Problem: Cmdline buffer is not cleared for a new message (since c973c7ae),
resulting in an incorrect spill indicator. When the cmdline
buffer is cleared, "msg_row" is not invalidated, resulting in
an error. The extui module is untested.
Return value of `vim.ui_attach()->callback` is undocumented.
Solution: Clear the cmdline buffer for the first message in an event
loop iteration. Ensure msg_row passed as end_row does not
exceed buffer length.
Add `messages_spec2.lua` to test the extui module, keeping in
mind that test coverage will greatly increase if this UI is made
the default. As such, only tests for specific extui functionality
unlikely to be covered by tests leveraging the current message grid.
Document the return value of `vim.ui_attach()->callback`, it seems
to make sense, and is also used to suppress remote UI events in
`messages_spec2.lua`.
Problem: Current window is checked to determine whether "more" window
is open. Making it the current window is scheduled in case the
cmdwin is open so this can be too late.
"cmdline_hide" may be emitted when the topline is
temporarily invalid (after incsearch->restore_viewstate()).
Solution: Use the window visibility to determine an active "more"
window instead.
Don't nvim__redraw->flush the "cmdline_hide" event (a normal
will already happen).
Problem: When opening a new tabpage, extui windows are initialized with
their default config. Window visiblity/dimensions on other
tabpages may get out of sync with their buffer content.
Solution: Copy the config of the window to the new tabpage.
No longer keep track of the various windows on each tabpage.
Close windows on inactive tabpages instead (moving them could
be more efficient but is currently not supported in the API).
Problem: Message lines from multiple message events that end up
spilling 'cmdheight' end up spread out over the cmdline
and "more" window.
Messages emitted as feedback to a typed :command (rather than
its sole purpose like :echo/:=) are routed to the more window.
The more window isn't closed when entering the cmdwin, and
doesn't allow `vim.hl.on_yank()`.
Solution: When first opening the "more" window for spilled messages,
move the message buffer to the more window.
Restrict routing of typed commands to echo kinds.
Ignore all events but WinLeave and TextYankPost.
Problem: Hint message to press "g<" for message that spills
'cmdheight' is too intrusive.
Solution: Remove the hint message. Document the meaning of the spill
indicator instead.
Problem: Unable to discern windows used by the extui interface
to configure their local options.
'winblend' may be detrimental to legibility depending on the
colorscheme and 'background'.
Solution: Assign the "cmdline", "msgmore", "msgprompt" and "msgbox"
'filetype' to the respective windows.
Don't set 'winblend' for the message "box" window.
Problem: Extui does not route messages emitted as a result of a typed
command to the "more" window.
Command message leading shell messages is missing a kind.
Messages not routed to 'cmdheight' area after it was 0.
Solution: Route messages that were emitted in the same event loop as an
entered command to the "more" window. Also append multiple
messages in an already open more-window.
Assign it the `shell_cmd` kind.
Change message position when 'cmdheight' changes from 0.
Problem: The "box" window width is calculated on the last line when
applying "last" virt_text. There may be longer lines
part of the same message.
Solution: Don't decrease box width if the calculated width is smaller.
Minor unrelated changes.
Co-authored-by: Eike <eike.rackwitz@mail.de>
Problem: More-window is left visible after leaving it. Cursor may be
hidden behind it and it is hard to re-enter afterwards.
Solution: Close the more-window when another window is entered.
Problem: Not picking up configured option values when enabling _extui after startup.
Solution: Check option values when enabing _extui.
Fix https://github.com/neovim/neovim/issues/33767
Problem: We have an unmaintained Vimscript parser and cmdline
highlighting mechanism, with which it is hard to leverage the
treesitter highlighter. Long messages result in a hit-enter-prompt.
Solution: Implement a vim.ui_attach() UI, that replaces the message
grid (orphaning some 3000+ LOC core C code). Introduce an experimental
vim._extui module, because removing the message grid at the same time is
too risky. The new UI leverages the bundled treesitter highlighter and
parser for Vimscript, as well as the matchparen plugin, to highlight the
cmdline. Messages are truncated in the cmdline area, or placed in a
floating message box in the bottom right corner. Special ("list_cmd")
messages and the message history are shown in a, "more prompt" (now a
fully interactive regular window). Various default UI elements ('showcmd',
'ruler') are also placed in the cmdline area, as virtual text.
`require('vim._extui').enable({})` enables the experimental UI.
`{ msg.pos = 'box' }` or `:set cmdheight=0` enables the message
box variant.
Followup:
- Come to a consensus for how best to represent messages (by default).
- Start removing message grid when this is deemed a successful replacement.
When that is finished, make this new UI the default and update a lot of tests.
