Problem: converting a split to a floatwin may not remove the last statusline
when needed. (e.g: 'ls' is 1)
Solution: call last_status/win_comp_pos in win_new_float, after win_remove.
Also fix float_pos formatting for screen snapshots so it doesn't give a nil
error for external windows.
Not an issue from this PR.
Problem:
When a terminal process exits, "[Process Exited]" text is added
to the buffer contents.
Solution:
- Return `exitcode` field from `nvim_get_chan_info`.
- Show it in the default 'statusline'.
- Show exitcode as virtual text in the terminal buffer.
Problem: vim.ui_attach() is unable to display streamed shell output,
and will display it as individual messages.
Unwanted newlines in "shell_ret" message.
Solution: Treat the "shell_*" kinds as non-fast and set msg_show->append
for the streamed stdout/err messages.
Remove leading newline from (translated) message with
ext_messages, remove trailing newline altogether.
Problem: Unable to tell whether a msg_show event is emitted as a result
a command typed on the cmdline (UI may want to represent these
differently from other messages).
Solution: Add trigger parameter that is set to "typed_cmd" for
a message emitted due to an interactively typed command.
Possible extensions are mapping/timer/event but it's hard to
imagine a UI distinguishing those so not added here.
Problem: Newlines emitted with ext_messages intended to position
the message/prompt on the message grid.
Solution: Don't emit these newlines with ext_messages, followup to 4260f73e.
Problem: UIs put ins-completion "scanning" messages one after another,
which are meant to overwrite the previous message.
Solution: Ensure the msg_show "replace_last" parameter is set.
Define a CMake target for every subdirectory of test/functional that
contains functional tests, and a functionaltest_parallel target that
depends on all those targets, allowing multiple test runners to run in
parallel.
On CI, use at most 2 parallel test runners, as using more may increase
system load and make tests unstable.
Problem: Newlines intended to write messages below the cmdline or to
mark the start of a new message on message grid are emitted
through ext_messages. This results in unnecessary newlines for
a UI that has decoupled its message area from the cmdline.
msg_col is set directly in some places which is not transmitted
to msg_show events.
Various missing message kind for list commands.
Trailing newlines on various list commands.
Solution: Only emit such newlines without ext_messages enabled.
Use msg_advance() instead of setting msg_col directly.
Assign them the "list_cmd" kind.
Ensure no trailing newline is printed.
Problem: "first" parameter added in 912388f5 for grouping printed lines
in a single event is ineffective for the :global command.
Solution: Only set the message kind for the first printed line during a
:global command.
Problem: Internal messages do not have an ID, which is unexpected and
undocumented.
Solution: Always assign a msg_id to msg_show events, simplifying
logic/expectations for UIs.
Problem: No empty msg_ruler event after leaving a window whose ruler
is not part of the statusline with 'rulerformat'.
Solution: Properly keep track of when a ruler event was emitted with
'rulerformat' to emit clear event.
Problem:
On Windows, writing to a pipe doesn't work if the pipe isn't connected
yet. This causes an RPC request to a session newly created by connect()
to hang, as it's waiting for a response to a request that never reaches
the server.
Solution:
Wait for uv.pipe_connect() callback to be called when using connect().
Problem:
The :intro fails to display in ui2 because wait_return(true) triggers a full
redraw. Furthermore statuslines are visible when using :intro
Solution:
Replace wait_return() with plain_vgetc(). This works with old and ui2 while also removing the unnecessary statusline and "press ENTER" prompt.
Updates tests to work with new behaviour.
Signed-off-by: ashab-k <ashabkhan2000@gmail.com>
Problem: A message ending in an unprintable character may emit a
msg_show event with the "empty" kind. No empty message event
for echom "".
Solution: Adjust conditions for emitting "empty" msg_show events.
Problem:
We want to encourage implementing core features in Lua instead of C, but
it's clumsy because:
- Core Lua code (built into `nvim` so it is available even if VIMRUNTIME
is missing/invalid) requires manually updating CMakeLists.txt, or
stuffing it into `_editor.lua`.
- Core Lua modules are not organized similar to C modules, `_editor.lua`
is getting too big.
Solution:
- Introduce `_core/` where core Lua code can live. All Lua modules added
there will automatically be included as bytecode in the `nvim` binary.
- Move these core modules into `_core/*`:
```
_defaults.lua
_editor.lua
_options.lua
_system.lua
shared.lua
```
TODO:
- Move `_extui/ => _core/ui2/`
Problem:
:messages history include the "search hit BOTTOM, continuing at TOP" message,
which is noise.
Solution:
Set msg_hist_off before giving the warning and reset it after warning.
Problem: regression when displaying localized percentage position
(after v9.1.1291)
Solution: calculate percentage first (Emir SARI)
Cleanups made in ec032de broke the Turkish percent display, failing to
prepend it properly in cases between 0 and 10. In Turkish, the percent
sign is prepended to the number, so it was displaying it as `% 5`
(should have been `%5`), while displaying numbers bigger than 9 properly.
related: vim/vim#175978fe9e55a7d
The test was unskipped in Vim in patch 9.1.1479 which added Turkish
translation for "%d%%". However, Nvim has had Turkish translation for
"%d%%" since 2023, so don't skip the test.
Co-authored-by: Emir SARI <emir_sari@icloud.com>
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.
- 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:
`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`.
Problem: Unicode has deprecated some code-points
Solution: Update the digraph tables to align with the Unicode v16
release (David Friant)
This commit updates the digraphs Left-Pointing Angle Bracket '</'
and Right-Pointing Angle Bracket '/>' to account for the fact that
the old Unicode codepoints for them (2329 and 232A, respectively)
have been deprecated. As per the Miscellaneous Technical code chart
(https://www.unicode.org/charts/PDF/U2300.pdf), the old digraphs
have been reassigned to the CJK Left Angle Bracket and Right Angle
Bracket (3008 and 3009) with their declaration moved to the
appropriate block.
This commit also introduces the new digraphs '<[' and ']>' to
represent the Mathematical Left Angle Bracket and Mathematical
Right Angle Bracket (27E8 and 27E9) to replace the deprecated code
points in the Technical block.
Tests have been added and, I believe, the documentation has been
updated accordingly.
closes: vim/vim#17990c08b94b072
Co-authored-by: David Friant <friant@HPEnvyx360.friant.dev>
Problem: The maximum search count uses a hard-coded value of 99
(Andres Monge, Joschua Kesper)
Solution: Make it configurable using the 'maxsearchcount' option.
related: vim/vim#8855fixes: vim/vim#17527closes: vim/vim#17695b7b7fa04bf
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: Hardcoded highlight IDs for ext_messages/cmdline output need
to be adjusted everytime a builtin highlight group is added.
Solution: Store a global map of default highlights through nvim_get_hl()
and fetch missing (custom) highlight groups through synIDattr().
Use more compact formatting for screen:expect().
Problem: Unable to tell whether msg_history_show event is emitted for a
:messages or g< command.
Solution: Add "prev_cmd" argument that is set to true for g<.
Problem: ext_messages cannot tell when the screen was cleared, which is
needed to clear visible messages. An empty message is also
never emitted, but clears messages from the message grid.
Solution: Repurpose the "msg_clear" event to be emitted when the screen
was cleared. Emit an empty message with the `empty` kind to
hint to a UI to clear the cmdline area.
Problem: ext_messages is implemented to mimic the message grid
implementation w.r.t. scrolling messages, clearing scrolled
messages, hit-enter-prompts and replacing a previous message.
Meanwhile, an ext_messages UI may not be implemented in a way
where these events are wanted. Moreover, correctness of these
events even assuming a "scrolled message" implementation
depends on fragile "currently visible messages" global state,
which already isn't correct after a previous message was
supposed to have been overwritten (because that should not only
happen when `msg_scroll == false`).
Solution: - No longer attempt to keep track of the currently visible
messages: remove the `msg_ext(_history)_visible` variables.
UIs may remove messages pre-emptively (timer based), or never
show messages that don't fit a certain area in the first place.
- No longer emit the `msg(_history)_clear` events to clear
"scrolled" messages. This opens up the `msg_clear` event to
be emitted when messages should actually be cleared (e.g.
when the screen is cleared). May also be useful to emit before
the first message in an event loop cycle as a hint to the UI
that it is a new batch of messages (vim._extui currently
schedules an event to determine that).
- Set `replace_last` explicitly at the few callsites that want
this to be set to true to replace an incomplete status message.
- Don't store a "keep" message to be re-emitted.
Problem: No ext_messages kind for the :command, :version commands.
:version is emitted as multiple events.
Solution: Assign them the "list_cmd" kind. Use `msg_put*` to properly
format the message as a single event.
Problem: The "append" parameter added in abb40ece is missing from
history entries, resulting in different message formatting
for "g<".
Solution: Add "append" field to message history entries.
Co-authored-by: phanium <91544758+phanen@users.noreply.github.com>
Problem: When using 'winblend', transparent backgrounds (-1) are forced
to default colors (usually black) during attribute blending, breaking
the transparency effect.
Solution: Check original background colors before blending in
hl_blend_attrs(). If both background and foreground originally had
transparent backgrounds, preserve transparency instead of forcing
default colors.
Problem: "msg_history_show" event is emitted when `msg_silent > 0`.
E.g. when capturing its output with `execute()`, which also
doesn't work with ext_messages.
Solution: Don't emit the "msg_history_show" event when `msg_silent > 0`.
Call regular messaging functions when `redirecting()`, to
execute `redir_write()` while ensuring the message itself
is not emitted.
Problem: not easily possible to complete from register content
Solution: add register-completion submode using i_CTRL-X_CTRL-R
(glepnir)
closes: vim/vim#173540546068aae
Problem: Unable to emit a message with arbitrary kind.
Solution: Add a "kind" opts field to nvim_echo().
Use it to set the "list_cmd" kind for vim.show_pos().
Problem: "99 searchcount ought to be enough for anyone."
Solution: Increase `SEARCH_STAT_DEF_MAX_COUNT` to 999, which I'm sure
will suffice for the next twenty years.
Co-authored-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
Problem: Consecutive "msg_show" events stemming from an `:echon`
command are supposed to be appended without a newline, this
information is not encoded in the "msg_show" event.
Solution: Add an "append" parameter to the "msg_show" event that is set
to true to indicate the message should not start on a new line.
Considered alternative: Emit a newline for the common case instead at the
start of a new message. That way UIs can more closely follow the logic
as it is implemented for the message grid currently. This would be a
breaking change. The "append" parameter seems OK.
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: Messages that are already added to the history are not emitted
as part of the "g<" msg_history_show event.
Solution: Move clearing the history for temporary messages to before
adding a message to the history, rather than after emitting
a message.
Problem: Missing kind and separate event for each line for message
containing buffer lines for e.g. `:print`.
Solution: Set the `list_cmd` kind and only `msg_start()` for the first
message, print a newline instead.
Problem: Ruler is not cleared from the screen/ext_messages state when
it is no longer drawn after e.g. `set noruler` or when moving
from a floating to a regular window.
Solution: Remember if ruler was drawn and clear it.
Problem:
stderr messages from executing ":!cmd" show up with
highlight hl-ErrorMsg. But some shell utilites use stderr for debug
logging, progress updates, etc.
Solution:
Highlight shell command outputs hl-StderrMsg and hl-StdoutMsg.
