This is the command invoked repeatedly to make the changes:
:%s/^\(.*\)|\%(\*\(\d\+\)\)\?$\n\1|\%(\*\(\d\+\)\)\?$/\=submatch(1)..'|*'..(max([str2nr(submatch(2)),1])+max([str2nr(submatch(3)),1]))/g
Previously, 'rightleftcmd' was implemented by having all code which
would affect msg_col or output screen cells be conditional on `cmdmsg_rl`.
This change removes all that and instead implements rightleft as a
mirroring post-processing step.
Problem:
Crash from:
set cmdheight=0 redrawdebug=invalid
resize -1
Solution:
Do not invalidate first `p_ch` `msg_grid` rows in `update_screen` when
scrolling the screen down after displaying a message, because they may
be used later for drawing cmdline.
Fixes#22154
Problem: Using freed memory when 'tagfunc' wipes out buffer that holds
'complete'.
Solution: Make a copy of the option. Make sure cursor position is valid.
0ff01835a4
Cherry-pick a cmdwin change from patch 9.0.0500.
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: incorrect heights in win_size_restore()
Solution: avoid restoring incorrect heights in win_size_restore()
876f5fb570
I already merged this prior, so just replace the new test with the old one,
but add a test case for the global statusline.
Currently it only skips if `Rows` changed, but it's possible for the height of
the usable area for windows to change (e.g: via `&ch`, `&stal` or `&ls`), which
can cause the value of `&cmdheight` to change when the sizes are restored.
This is a Vim bug, so I've submitted a PR there too. No telling when it'll be
merged though, given the current lack of activity there.
`ROWS_AVAIL` is convenient here, but also subtracts the `global_stl_height()`.
Not ideal, as we also care about the height of the last statusline for other
values of `&ls`. Meh.
Introduce `last_stl_height` for getting the height of the last statusline and
use it in `win_size_save/restore` and `last_status` (means
`last_status_rec`'s `statusline` argument will now be true if `&ls` is 3,
but that does not change the behaviour).
Also corrects the logic in `comp_col` to not assume there's a last statusline
if `&ls` is 1 and the last window is floating.
Redrawing of 'statusline' and 'winbar' are actually already inhibited by
RedawingDisabled in Ex mode.
In Vim there is a check for `msg_scrolled == 0` (which is false in Ex
mode) since Vim doesn't have msgsep. Add a `!exmode_active` check here
in Nvim instead.
scroll_delta contains how much the top line of a window moved since the
last time win_viewport was emitted. It is expected to be used to
implement smooth scrolling. For this purpose it only counts "virtual" or
"displayed" so folds should count as one line. Because of this it
adds extra information that cannot be computed from the topline
parameter.
Fixes#19227
Extend the capabilities of is_os to detect more platforms such as
freebsd and openbsd. Also remove `iswin()` helper function as it can be
replaced by `is_os("win")`.
The old behaviour (e.g. via `set display-=msgsep`) will not be available.
Assuming that messages always are being drawn on msg_grid
(or not drawn at all, and forwarded to `ext_messages` enabled UI)
will allows some simplifcations and enhancements moving forward.
Problem: Command line is not cleared when switching tabs and the command
line height differs.
Solution: Set the "clear_cmdline" flag when needed. (Naruhiko Nishino,
closesvim/vim#5495)
479950f6c9
Problem: 'verbose' value 16 causes duplicate output.
Solution: Combine levels 15 and 16 into one message. (Christian Brabandt,
closesvim/vim#6153)
823654bc06
It is perfectly fine and expected to detach from the screen just by
the UI disconnecting from nvim or exiting nvim. Just keep detach() in
screen_basic_spec, to get some coverage of the detach method itself.
This avoids hang on failure in many situations (though one could argue
that detach() should be "fast", or at least "as fast as resize",
which works in press-return already).
Never use detach() just to change the size of the screen, try_resize()
method exists for that specifically.
(<Cmd>0<cr> is not really a no-op, it moves the cursor.)
Attempt to avoid flaky test:
test/functional/ui/cmdline_spec.lua @ 830
Failure message: ./test/functional/ui/screen.lua:579: Row 2 did not match.
Expected:
| |
|*{1:~ }|
|{3: }|
|:012345678901234567890123|
|456789^ |
Actual:
| |
|*{3: }|
|:012345678901234567890123|
|:012345678901234567890123|
|456789^ |
./test/functional/ui/screen.lua:579: in function '_wait'
./test/functional/ui/screen.lua:367: in function 'expect'
test/functional/ui/cmdline_spec.lua:841: in function <test/functional/ui/cmdline_spec.lua:830>
ref https://github.com/neovim/neovim/pull/10171#issuecomment-520134344
ref #10171
Avoid clearing the screen in most situations. NOT_VALID should be
equivalent to CLEAR unless some external force messed up the terminal,
for these situations <c-l> and :mode will still clear the screen.
Also eliminate some obsolete code in screen.c, that dealt with that in
vim drawing window 1 can mess up window 2, but this never happens in
nvim.
But what about slow terminals? There is two common meanings in which
a terminal is said to be "slow":
Most commonly (and in the sense of vim:s nottyfast) it means low
bandwidth for sending bytes from nvim to the terminal. If the screen is
very similar before and after the update_screen(CLEAR) this change
should reduce bandwidth. If the screen is quite different, but there is
no new regions of contiguous whitespace, clearing doesn't reduce
bandwidth significantly. If the new screen contains a lot of whitespace,
it will depend of if vsplits are used or not: as long as there is no
vsplits, ce is used to cheaply clear the rest of the line, so
full-screen clear is not needed to reduce bandwith. However a left
vsplit currently needs to be padded with whitespace all the way to the
separator. It is possible ec (clear N chars) can be used to reduce
bandwidth here if this is a problem. (All of this assumes that one
doesn't set Normal guibg=... on a non-BCE terminal, if you do you are
doomed regardless of this change).
Slow can also mean that drawing pixels on the screen is slow. E-ink
screens is a recent example. Avoiding clearing and redrawing the
unchanged part of the screen will always improve performance in these
cases.
