Problem: 'listchars' "leadtab" not used in :list (after 9.2.0088).
Solution: Also check for "leadtab" when using :list. Fix memory leak on
E1572 if "multispace" or "leadmultispace" is set (zeertzjq).
closes: vim/vim#195575845741d69
Problem: Leading message newlines (not emitted with ext_messages since
4260f73) were responsible for resetting the redirection message
column (while the newline itself is later pruned...).
Solution: Ensure the redirection column is reset at the start of a message.
(Instead of re-adjusting all the newline callsites which can
themselves hopefully be pruned if ext_messages is enabled by
default.)
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:
- Editing a 'readonly' file forces a 3-second delay.
- nvim_get_mode waits 3 secs with 'showmode' enabled or when there are error messages.
Solution:
Remove the delay for "ui2", by using `msg_delay`.
Problem:
When MsgArea highlight is changed, the next message may flash
and disappear because msg_start() renders with stale highlight attributes.
msg_puts_len() uses HL_ATTR(HLF_MSG) to render message text, which
happens before update_screen() calls highlight_changed().
So the message is rendered with outdated attrs.
Solution:
Call highlight_changed() in msg_start().
Problem: Logic determining messages belonging to the last command to
show with "g<" does not flush pending messages. This can
result in clearing the temporary message history before a
message still belonging to the previous command was emitted.
Solution: Flush pending messages when marking the end of messages
belonging to previous command.
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: Message ID is not incremented without ext_messages.
Solution: Increment where callstack reaches without ext_messages.
There is no clear place marking the end of internal
messages without ext_messages so IDs are only incremented
with `nvim_echo` calls. Message IDs are currently not exposed
anywhere but the msg_show event for this to matter.
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: 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:
Tests that trigger `os_delay` messages may take 1-3 seconds, wasting
build/CI time, since this serves no purpose in tests.
Solution:
- Introduce `msg_delay` for cases where `os_delay` is being used as
a "UI feature".
- Skip `msg_delay` in tests.
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: Wrong cursor position after formatting with long 'formatprg'.
Solution: Don't show hit-enter prompt when there are stuffed characters.
Previously a stuffed character at the hit-enter prompt will dismiss the
prompt immediately and be put in the typeahead buffer, which leads to
incorrect behavior as the typeahead buffer is processed after the stuff
buffers. Using vungetc() when KeyStuffed is TRUE can fix this problem,
but since the hit-enter prompt isn't visible anyway (and is likely not
desired here), just skip the prompt instead, which also avoids a wait
when using "wait" instead of "hit-enter" in 'messagesopt'.
fixes: vim/vim#18905closes: vim/vim#1890650325c3d59
Problem:
With vim.ui_attach in headless mode, messages are still printed.
Solution:
Don't print to stdout if a vim.ui_attach "messages" handler is defined.
Problem: When exiting at the end of the more prompt (at the hit enter
prompt) by hitting q the recording mode will be started.
(Jakub Łuczyński)
Solution: Don't add the q key to the typeahead buffer
in the function wait_return (Bjoern Foersterling)
fixes: vim/vim#2589closes: vim/vim#18889ecce3497fa
Co-authored-by: Bjoern Foersterling <bjoern.foersterling@gmail.com>
Problem: Crash when allocating signal stack fails.
Solution: Only using sourcing info when available. (closesvim/vim#9215)
0bd8d05638
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: CTRL-F and CTRL-B don't work in more prompt
Solution: Make CTRL-F and CTRL-B scroll by a screen down/up
(Bjoern Foersterling)
closes: vim/vim#18545fcf4c435af
Co-authored-by: bfoersterling <bjoern.foersterling@gmail.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: 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`.
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: Functions used in one file are global.
Solution: Add "static". (Yegappan Lakshmanan, closesvim/vim#4840)
5843f5f37b
Co-authored-by: Bram Moolenaar <Bram@vim.org>
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: 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: Since 48e2a736, prompt messages are handled by an actual
active cmdline, resulting in `State` no longer being equal
to `MODE_CONFIRM` which is used in some places. E.g. to
specify the current `mode()` or to re-emit a confirm message.
Solution: Replace `MODE_CONFIRM` with a new `MODE_CMDLINE` sub-mode when
`ccline.one_key/mouse_used` is set. Use it to avoid clearing
mouse_used prompt messages, and to re-emit one_key messages
(when ext_messages is inactive, for which this is unnecessary).
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: 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: 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: Delay for reading a message may be unwanted for ext_messages,
and can be done by the implementation. Empty completion source
error message is not distinguishable as such.
Solution: Only delay without ext_messages enabled. Emit empty completion
source message as an error.
Problem: Message kind logic for emitting an error message is convoluted
and still results in emitting an unfinished message earlier than
wanted.
Solution: Ensure emsg_multiline() always sets the kind wanted by the caller
and doesn't isn't unset to logic for emitting the source message.
Caller is responsible for making sure multiple message chunks are
not emitted as multiple events by setting `msg_ext_skip_flush`...
