| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
position #42105
vim-patch:9.2.1114: Visual selection is not highlighted at the cursor position
Problem: In a terminal the character under the cursor is normally not
shown as part of the visual selection.
Solution: Don't set "noinvcur" in win_line() (Shane Harper).
The problem did not occur in the GUI, only in a terminal.
The name "noinvcur" ("don't invert the cursor") was misleading: the
variable did not affect the cursor, but whether the character under the
cursor could be displayed as part of the visual selection.
The "noinvcur" handling may have been meant to help during a visual
selection when Visual is shown in reverse video and the terminal draws
the cursor by inverting the character under it, as otherwise the
character under the cursor would not look highlighted like the rest of
the selection. But Vim cannot know in general how a terminal draws the
cursor, and when either the cursor is not drawn by inverting the
character under it or Visual is not shown in reverse video, the handling
just left a character of the visual selection unhighlighted.
closes: vim/vim#21317
https://github.com/vim/vim/commit/d10aab4ba6602f8f2f2576d2d62ceb63869db6fb
Co-authored-by: Shane Harper <shane@shaneharper.net>
AI-assisted
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Other (squashed) commits:
fix(tui): emit ui_send output atomically with the frame
Problem:
tui_ui_send() writes directly to the TTY, bypassing the output buffer.
Sequences sent via nvim_ui_send() (e.g. kitty multiple-cursors, or
visual-dot-repeat) always arrive in a separate TTY write from the frame
they were computed for. This manifests as "tearing", or e.g. in the case
of multicursor the terminal renders text with stale cursor overlays.
Solution:
- tui_ui_send(): while a frame is being assembled (pending invalid
regions or buffered output), buffer instead of writing directly.
- Out-of-frame sends (tty queries, clear-on-disable) still write
immediately.
- mcursor.lua: emit the terminal-cursor update at the end of the redraw
cycle (`on_end`, when screen positions are final) instead of
vim.schedule().
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
1. `ctx_dirs_restore()` is the only chdir site that doesn't re-shorten
buffer names; `post_chdir()`, `update_cwd()` and `do_autochdir()` all
call `shorten_fnames(true)`. So after a temp window-context switch
that moved the CWD, every buffer's `b_fname` is still relative to the
other directory. ui2 renders messages in a float, and entering it is
such a switch, so with a `:bcd` in a `BufReadPost` handler 'statusline'
"%f" shows ".config/nvim/init.lua" while the CWD is already
`~/.config/nvim`, and :write resolves the name against it:
```
E212: Can't open file for writing: no such file or directory
```
2. `msg_multihl()` leaves `msg_ext_id` pointing at the caller's storage
when nothing was emitted (e.g. 'msg_silent'): the reset only ran on
a flush that produced chunks. The next message then ships a dead
stack frame as its msg_show id. After ":silent write" the id is
buf_write()'s `msg_id[MAXPATHL + 32]`:
```
id = "\0\0\0\0\0\0\0\0\29\0(<C6>k\24R\17p<C7><C7><C7>\1\0\0\0..."
```
Solution:
1. `shorten_fnames(true)` after restoring the CWD. Drop `cs_save_sfname`,
which was a partial workaround for the same bug.
2. Release the id in `msg_multihl()`, where it is set and the caller's
frame is still alive. Stop reading `.data.integer` out of a String
union member.
|
| |
|
|
|
|
|
|
|
|
| |
Problem:
`inputlist()` advertises "click with the mouse" purely because it
implements click selection, so under the default `'mouse'` of "nvi" it
offers a click that command-line mode never receives.
Solution:
Only offer the mouse when `'mouse'` covers command-line mode, the same
condition `:help inputlist()` already documents.
|
| |
|
|
|
|
|
|
|
| |
Problem:
The insert-mode completion progress-message is in "running" state while
the user is selecting an item. That is noisy and unwanted UX; it was
only intended for the "Scanning..." task.
Solution:
End the progress-msg just after `ins_compl_show_statusmsg`.
|
| |
|
|
|
|
|
|
|
|
| |
Problem:
Some builtin features emit progress-messages which never "complete".
- On failure, `:write` does not complete the progress-msg it started.
- ins-completion never ends its "Scanning..." message.
Solution:
- `buf_write()` emits "failed" status on failure.
- `ins_compl_stop()` ends the completion one.
|
| |
|
|
|
|
|
|
|
|
|
| |
Problem:
filemess() treats an empty suffix as "a buffer write is starting", but
readfile() calls it that way too. So ":read" (and ":edit", …) opens a
`nvim.bufwrite "<file>"` progress that is never completed.
Users of e.g. ghostty will see a stuck "progress" spinner.
Solution:
Only `buf_write()` starts the progress, via `filemess_progress()`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
The default 'ruler' is implemented in C instead of the 'statusline' DSL.
Solution:
Replace the C implementation with a default 'rulerformat' expression.
This is a continuation of #1248 and #33036.
Advantages:
- configuration is more discoverable, the default being a useful example
- users and plugins can augment the default
- code reuse and less C code to maintain
- ui2: due to the use of an item group with `minwid`, it can expand
instead of truncating when the content gets too long, which is
particularly useful for locales with long translations of Top/Bot/All
Implementation details:
As is the case for 'statusline', when trying to set 'rulerformat' to an
empty string, the default expression is restored instead, mimicking how
previously the default C implementation would have been activated.
Just like before, `:set rulerformat=` and `:set rulerformat&` have the
same effect, and the ruler is disabled with `:set noruler`.
The default expression uses an item group with `%=`, unlike the fallback
in the previous default statusline `%-14.(%l,%c%V%) %P`, because the
total width and how it is configured is immediately clear without
documentation, it is a more useful pattern in general that works when
both sides have flexible width, and it also works for vim, which is
useful for configuration sharing/reuse.
A truncation marker `%<` is added at the end to mimic how at small
screen widths, the scroll percentage would disappear first, so that the
cursor position can remain fully visible.
BREAKING CHANGES:
- `&rulerformat` can no longer be set to an empty string
- ui2: the default ruler is no longer of fixed width, but can expand
- at very small screen widths (< 36 columns)
- ui2: it will no longer try to shrink white-space before truncating
- it truncates gradually from the right, whereas previously, the
scroll percentage would disappear all at once
- l10n can no longer add a space after the comma between line and column
(this was only done for one language: Ukrainian)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: Traditionally, the ruler in the last line is one cell shorter
than in the statusline, leaving the last cell of the screen blank.
According to code comments, this is in order to prevent unwanted
scrolling on "some" (unspecified, but presumably ancient) terminals.
Berkeley vi is more specific in its `vs_modeline` function: dumb
terminals with hardware scroll, SunOS 4.1.1 and Ultrix 4.2 curses.
(n)curses still has a similar limitation in `(w)addstr`, but apparently
only for historical reasons.
Maintaining the different widths leads to awkward inconsistencies when
the ruler is configured with 'rulerformat', except for the special case
where it contains a top-level `%=`. Shifting the ruler in the last line
to the left would be a solution, but the empty cell at the end doesn't
seem to be relevant anymore.
Solution: extend the ruler in the last line all the way to the right
edge of the screen, just like in the statusline. The exact same amount
of place will be available to the rest of the UI as before.
BREAKING CHANGE:
- the default ruler width is now 18 cells
- the last cell of the screen is no longer empty
Closes #41076
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: the ruler is not cleared in the following circumstances:
- ui1 is running
- 'rulerformat' is configured
- the default ruler was not previously visible in the last line, for
example because 'rulerformat' is configured in init.lua
- 'ruler' is disabled without using the command-line, for example via
key-binding (entering the command-line would clear the ruler)
The corresponding test case did not fail because 'rulerformat' was set
while the default ruler was shown.
Solution: use a dedicated variable for tracking whether the ui1 ruler
was previously shown in the last line. `did_ruler_col` is now only used
for setting `msg_col`, which is not implemented in the case where
'rulerformat' is configured.
Reorder the test code to make the individual checks more independent
from each other, and to reflect the future where 'rulerformat' will
never be empty. Note that the check where 'rulerformat' was configured
relied on the default ruler not being cleared and a stale "0," still
being shown in front of the new ruler - this is also fixed with ui2.
|
| |
|
|
|
|
|
|
|
| |
Problem:
Want `gQ` for _le multicursor_.
Solution:
- Don't use `gQ` for exmode.
- Introduce `:exmode`.
- Introduce `[count]q:` as an alias to `:exmode`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
POSIX-compatible Ex-mode requires special-cases all over the codebase to
match various quirks that don't actually matter to users.
- The main utility of *interactive* Ex-mode is its REPL behavior, and
that can be achieved with `cmdwin`, which also gains extra UX
benefits.
- The main utility of *non-interactive* `nvim -es` is for shell
scripting, where Ex-mode quirks are mostly unhelpful (e.g. the
"Entering Ex mode" message).
Solution:
- Reimplement *interactive* Ex-mode as a "persistent, insert-mode
cmdwin" in Lua.
- "nvim -e/-E" is simply an alias to "gQ".
- Reframe *non-interactive* Ex-mode (`nvim -es`) as "script mode".
- Drop POSIX Ex-mode quirks.
Improvements:
- "nvim -V1 -es" output ends with a final newline!
- "nvim -V1 -es" no longer shows the "Entering Ex mode" msg. (This was
pointless noise, unwanted for scripting purposes.)
- stdin is no longer typeahead. Scripts (":lua io.read()") can read
stdin as data.
- Empty line is a no-op: a stray blank line no longer moves the cursor
(deviates from POSIX ex "+1"), no longer exits 1 at EOF (E501).
Preserved behavior:
- cursor starts at "$"
- mode()=="cv" (for non-interactive)
- multiline commands (:append/:function/heredoc pull continuation lines)
- bare-range print
- :print=>stdout
- -V1=>stderr
- CRLF input
- continue-after-error and exit codes
Dropped (regressed) POSIX behavior (non-interactive):
- Event loop only ticks while/between commands, not while blocked
waiting for a stdin line.
- ":g/pat/visual...Q"
- input()/getchar()/":s/x/y/c" no longer consume stdin lines as
answers: Nvim stops at end-of-input, skipping the rest of the script,
exit 0. Use ":lua io.read()" instead.
- If users care about this they should use interactive Ex-mode (`gQ`).
- ":@r" stops at end of the register instead of continuing to read
cmdline input from stdin.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
The magic globals `it`, `describe`, etc., are more trouble than they are
worth.
- Hooking into `after_each` requires `getfenv()` hacks.
- They confuse luals/emmylua, because the top-level `.luarc.json` isn't
merged with `test/.luarc.json` (apparently a luals limitation?)
- They totally defeat discoverability because the user just has to
"know" about the various magic symbols.
So they harm DX, which means they serve no purpose at all.
Solution:
- Expose the test API from `testutil`, so tests can call `t.it()`,
`t.describe()`, etc., in the conventional way.
- Drop `getfenv()` hacks.
- Drop the `setfenv()` injection in `load_chunk`.
- Drop `test/_meta.lua`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: before ui2, the ruler in the last line had a one cell safety
margin on the right because writing in the last column of the last line
"scrolls the screen up on some terminals," according to code comments.
When the ruler is included in the statusline, it aligns on the left with
the normal ruler, but goes all the way to the screen edge on the right,
and is therefore one cell longer.
Since ui2 doesn't have that padding cell, they don't align anymore.
Also, in the future, when the C implementation of the ruler will be
replaced with a default expression that will be included in the default
statusline (currently `%-14.(%l,%c%V%) %P`), the width will naturally be
the same in both places, and the unit tests will need adapting anyway.
Solution: when ui2 is active, increase the ruler width by 1.
BREAKING CHANGE: the default ruler in ui2 is now 1 cell wider.
ref https://github.com/neovim/neovim/issues/40247
|
| |
|
|
|
|
|
|
|
|
|
| |
Problem:
bufwrite message overridden by :redrawstatus command within Progress callback.
Solution:
- don't use globally-shared IObuf.
- use vim_snprintf to deduplicate `nlua_call_luaeval`, `nlua_call_vlua`.
fix https://github.com/neovim/neovim/issues/40616
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PROBLEM:
Cursor briefly flickers in cmdline when the "written" message is printed
(very noticeable in Neovide with cursor animation).
SOLUTION:
- Mark UI "busy" (cursor hidden) while emitting the message, as done for
the search message (cb2ca54331cd).
- Note: ff68fd6b8a84 moved the message from `filemess()` into
`buf_write..msg_progress`.
- Fix a bug in `tui.c:flush_buf` which manifested after this change. See
ANALYSIS below. https://github.com/libuv/libuv/issues/5182
ANALYSIS:
After this change...
ui_busy_start();
set_keep_msg(msg_progress(IObuff, msg_id, "success", 0, true, true), 0);
ui_busy_stop();
...ASAN analyzer fails on tui_spec.lua test "with non-tty (pipe) stdout/stderr":
2026-07-04T14:09:28.9521023Z = ==32405==ERROR: AddressSanitizer: ABRT on unknown address 0x03e900007e95
...
4 0x7f5506a288fe in abort stdlib/abort.c:79:7
5 0x559afd7113a2 in uv__epoll_ctl_flush
build/src/libuv/src/unix/linux.c:1335:7
6 0x559afd710a81 in uv__io_poll
build/src/libuv/src/unix/linux.c:1448:9
7 0x559afd6f67a7 in uv_run
build/src/libuv/src/unix/core.c:460:5
8 0x559afd2a72cc in flush_buf
nvim/tui/tui.c:2642:5
9 0x559afd2bce9f in tui_flush
nvim/tui/tui.c:1747:3
10 0x559afd2f39a0 in ui_client_event_flush
nvim/auto/ui_events_client.generated.h:64:3
11 0x559afcb8e014 in parse_msgpack
nvim/msgpack_rpc/channel.c:255:11
12 0x559afcb840e7 in receive_msgpack
nvim/msgpack_rpc/channel.c:217:5
13 0x559afc53b2af in read_event
nvim/event/rstream.c:180:23
14 0x559afc53ad52 in invoke_read_cb
nvim/event/rstream.c:233:3
15 0x559afc5382d6 in read_cb
nvim/event/rstream.c:135:3
16 0x559afd707b25 in uv__read
build/src/libuv/src/unix/stream.c:1145:7
17 0x559afd70744a in uv__stream_io
build/src/libuv/src/unix/stream.c:1208:5
18 0x559afd6f727e in uv__io_cb
build/src/libuv/src/unix/core.c:930:5
19 0x559afd710d7a in uv__io_poll
build/src/libuv/src/unix/linux.c:1546:11
20 0x559afd6f67a7 in uv_run
build/src/libuv/src/unix/core.c:460:5
21 0x559afc526e2d in loop_uv_run
nvim/event/loop.c:59:3
22 0x559afc526aa4 in loop_poll_events
nvim/event/loop.c:80:26
23 0x559afd2fdbb7 in ui_client_run
nvim/ui_client.c:172:5
24 0x559afc920d7b in main /home/runner/work/neovim/neovim/src/nvim/main.c:355:5
25 0x7f5506a2a1c9 in __libc_start_call_main
main.h:58:16
26 0x7f5506a2a28a in __libc_start_main csu/../csu/libc-start.c:360:3
27 0x559afbd6d254 in _start
The abort requires two rare conditions:
1. a `uv_write` whose buffer array *ends* in a zero-length buffer, which only
happens by "flush while cursor-hidden".
2. an output fd that *epoll cannot watch*. The only CI test with such an fd is
tui_spec.lua "with non-tty (pipe) stdout/stderr", which runs a TUI with
`stdout > /dev/null`, then runs `:w testF`, which triggers the "written"
message.
Our change guarantees trailing-empty flushes (`:w` fires busy + `ui_flush()`
while busy) in the only test that runs a TUI on `/dev/null`.
0. In a normal (non-busy) no-sync flush, post always contains `cursor_normal`.
1. Our change emits:
```
busy_start → msg_progress("…written") → ui_flush → busy_stop
```
2. TUI flushes *while busy*, so `should_invisible() = true` and `flush_buf`
skips the cursor-restore string (`bufs[2]` is zero-length).
3. libuv *cannot complete* a write whose tail is a zero-length buffer: EVERY
trailing-empty write goes through epoll, even when every byte was already
written. https://github.com/libuv/libuv/issues/5182
4. In `tui_spec.lua:3298`, the output fd is `/dev/null`, whose kernel
`file_operations` has no `.poll` method (`drivers/char/mem.c`), so
`EPOLL_CTL_ADD` fails with `EPERM`.
Trailing empty buffers are semantically pointless, and libuv punishes
them: forced async, one epoll round-trip *per trailing empty*, plus
a 0-byte `write()` syscall.
Helped-by: Shougo Matsushita <Shougo.Matsu@gmail.com>
Helped-by: Fred Sundvik <fsundvik@gmail.com>
|
| |
|
|
|
|
|
|
|
|
| |
Problem:
Listing individual "skipped" notices for each non-actionable or
NVIM_TEST_INTEG test is noisy and makes the "skipped" list overwhelming
and less meaningful.
Solution:
- Mark non-actionable tests with "N/A".
- Report NVIM_TEST_INTEG tests as a separate 1-line summary.
|
| |
|
|
|
|
|
|
|
| |
Problem: Internal progress messages use the "nvim" source (since
ff68fd6b), plugins shouldn't be allowed to set the progress
message source to "nvim". The message ID used for internal
progress messages is not identifiable as such.
Solution: Disallow setting opts->source to "nvim" with nvim_echo().
Refactor msg_progress() and callees to bypass nvim_echo().
Prepend message id for internal progress messages with "nvim.".
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
The fallback that tokenizes `eap->arg` by unescaped whitespace (when the
parser doesn't pre-split via `EX_EXPAND` etc.) lives in `nlua_do_ucmd`,
so only user-command callbacks got `eap.fargs`. Builtin commands routed
through `nlua_call_excmd` have to re-parse the args themselves
(e.g. `M.ex_lsp`).
Solution:
- Move the tokenization into `nlua_push_eap` so every Lua handler sees
`eap.fargs`. Keep only the `EX_NOSPC` override in `nlua_do_ucmd` (the
`nargs=1`/`?` case which is genuinely user-command-specific).
- Drop the re-parse in `M.ex_lsp`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
`:tselect` and `z=` (spell suggest) have their own bespoke select menus.
Solution:
- Delegate to `vim.ui.select` instead.
- Bonus:
- `:tselect` gains mouse support. `print_tag_list` didn't suport mouseclick.
This causes some minor regressions, which are not blockers:
- `z=` no longer draws the list right-left if 'rightleft' is set.
- TODO: can/should `vim.ui.select` / `vim.fn.inputlist()` handle that?
- `:tselect`
- No "column" headings (`# pri kind tag file`).
- No highlighting: (HLF_T: tag name, HLF_D: file, HLF_CM: extra fields).
- TODO: can `vim.ui.select()` support highlighted chunks (`[[text, hl_id], ...]`) ?
fix https://github.com/neovim/neovim/issues/25814
fix https://github.com/neovim/neovim/issues/31987
|
| |
|
|
|
|
|
| |
Problem:
No way to signal "unknown" or "indeterminate" progress percentage.
Solution:
Treat percent=nil as "indeterminate" percent.
|
| |
|
|
|
|
|
|
|
|
| |
Problem: The "Scanning:" completion, bufwrite, and indent (there may be
more) messages which indicate progress can use the "progress" kind
for their msg_show event. Indent message does not have a kind.
Solution: Emit these messages with the "progress" kind. Set the message id
to the replaced kind so that a UI knows to replace it (and to provide
a migration path in case a UI was distinguishing these messages for
whatever reason).
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Problem:
- Progress-events are filtered by "source". But "source" is not required by nvim_echo.
- Without "++nested" (force=false), nvim_echo in an event-handler does not trigger Progress events.
- vim.health does not declare a "source".
Solution:
- Make source mandatory for progress-messages
- Enable ++nested (force=true) by default when firing Progress event.
- Set "source" in vim.health module.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Problem:
Currently, there's no way to distinguish progress messages coming from
different sources. Nor can Progress event be easily filtered based on
source.
Solution:
- Add "source" field to nvim_echo-opts.
- The Progress event pattern is now defined by the "source" field.
- Include the "title" as ev.data.
- Unrelated change: set force=false to disable nesting.
|
| |
|
|
| |
Problem: No empty msg_show event for :echo without arguments.
Solution: Emit empty msg_show event when :echo is invoked without arguments.
|
| | |
|
| |
|
|
|
|
|
| |
Problem: Intro is not sexy.
Solution: Make it sexy.
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
`nvim_echo(…, {id=…})` accepts user-defined id as a string or integer.
Generated ids are always higher than last highest msg-id used. Thus
plugins may accidentally advance the integer id "address space", which,
at minimum, could lead to confusion when troubleshooting, or in the
worst case, could overflow or "exhaust" the id address space.
There's no use-case for it, and it could be the mildly confusing, so we
should just disallow it.
Solution:
Disallow *integer* user-defined message-id.
Only allow *string* user-defined message-id.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Problem:
No way to disable progress messages in cmdline message area. If
a third-party plugin handles Progress events + messages, the user may
not want the "redundant" progress displayed in the cmdline message area.
Solution:
Support "progress:c" entry in 'messageopts' option.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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: 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:
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: 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.
|
|
