This finalizes the long running refactor from the old TUI-focused grid
implementation where text-drawing cursor was not separated from the
visible cursor.
Still, the pattern of setting cursor position together with updating a
line was convenient. Introduce grid_line_cursor_goto() to still allow
this but now being explicit about it.
Only having batched drawing functions makes code involving drawing
a bit longer. But it is better to be explicit, and this highlights
cases where multiple small redraws can be grouped together. This was the
case for most of the changed places (messages, lastline, and :intro)
- Move vimoption_T to option.h
- option_defs.h is for option-related types
- option_vars.h corresponds to Vim's option.h
- option_defs.h and option_vars.h don't include each other
The screen grid refactors will continue until morale improves.
Jokes aside, this is quite a central installment in the series.
Before this refactor, there were two fundamentally distinct codepaths
for getting some text on the screen:
- the win_line() -> grid_put_linebuf() -> ui_line() call chain used for
buffer text, with linebuf_char as a temporary scratch buffer
- the grid_line_start/grid_line_puts/grid_line_flush() -> ui_line()
path used for every thing else: statuslines, messages and the command line.
Here the grid->chars[] array itself doubles as a scratch buffer.
With this refactor, the later family of functions still exist, however
they now as well render to linebuf_char just like win_line() did, and
grid_put_linebuf() is called in the end to calculate delta changes.
This means we don't need any duplicate logic for delta calculations anymore.
Later down the line, it will be possible to share more logic operating
on this scratch buffer, like doing 'rightleft' reversal and arabic
shaping as a 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
This is a step in an ongoing refactor where the "grid_puts" and
"grid_put_linebuf" code paths will share more of the implementation (in
particular for delta calculation, doublewidth and 'arabicshape'
handling). But it also makes sense by its own as a cleanup, and is thus
committed separately.
Before this change many of the low level grid functions grid_puts,
grid_fill etc could both be used in a standalone fashion but also as
part of a batched line update which would be finally transmitted as a
single grid_line call (via ui_line() ). This was initially useful to
quickly refactor pre-existing vim code to use batched logic safely.
However, this pattern is not really helpful for maintainable and newly
written code, where the "grid" and "row" arguments are just needlessly
repeated. This simplifies these calls to just use grid and row as
specified in the initial grid_line_start(grid, row) call.
This also makes the intent clear whether any grid_puts() call is actually
part of a batch or not, which is better in the long run when more things
get refactored to use effective (properly batched) updates.
This is not used as part of the logic to actually implement TUI line wrapping
In vim (especially gvim) it is used to emulate terminal-style text
selection. But in nvim we don't do that, and have no plans to reintroduce it.
Previously, a screen cell would occupy 28+4=32 bytes per cell
as we always made space for up to MAX_MCO+1 codepoints in a cell.
As an example, even a pretty modest 50*80 screen would consume
50*80*2*32 = 256000, i e a quarter megabyte
With the factor of two due to the TUI side buffer, and even more when
using msg_grid and/or ext_multigrid.
This instead stores a 4-byte union of either:
- a valid UTF-8 sequence up to 4 bytes
- an escape char which is invalid UTF-8 (0xFF) plus a 24-bit index to a
glyph cache
This avoids allocating space for huge composed glyphs _upfront_, while
still keeping rendering such glyphs reasonably fast (1 hash table lookup
+ one plain index lookup). If the same large glyphs are using repeatedly
on the screen, this is still a net reduction of memory/cache
consumption. The only case which really gets worse is if you blast
the screen full with crazy emojis and zalgo text and even this case
only leads to 4 extra bytes per char.
When only <= 4-byte glyphs are used, plus the 4-byte attribute code,
i e 8 bytes in total there is a factor of four reduction of memory use.
Memory which will be quite hot in cache as the screen buffer is scanned
over in win_line() buffer text drawing
A slight complication is that the representation depends on host byte
order. I've tested this manually by compling and running this
in qemu-s390x and it works fine. We might add a qemu based solution
to CI at some point.
Problem: Now way to show text at the bottom part of floating window
border (a.k.a. "footer").
Solution: Allows `footer` and `footer_pos` config fields similar to
`title` and `title_pos`.
Most of the messy things when changing a non-current buffer is
not about the buffer, it is about windows. In particular, it is about
`curwin`.
When editing a non-current buffer which is displayed in some other
window in the current tabpage, one such window will be "borrowed" as the
curwin. But this means if two or more non-current windows displayed the buffers,
one of them will be treated differenty. this is not desirable.
In particular, with nvim_buf_set_text, cursor _column_ position was only
corrected for one single window. Two new tests are added: the test
with just one non-current window passes, but the one with two didn't.
Two corresponding such tests were also added for nvim_buf_set_lines.
This already worked correctly on master, but make sure this is
well-tested for future refactors.
Also, nvim_create_buf no longer invokes autocmds just because you happened
to use `scratch=true`. No option value was changed, therefore OptionSet
must not be fired.
ml_get_buf() takes a third parameters to indicate whether the
caller wants to mutate the memline data in place. However
the vast majority of the call sites is using this function
just to specify a buffer but without any mutation. This makes
it harder to grep for the places which actually perform mutation.
Solution: Remove the bool param from ml_get_buf(). it now works
like ml_get() except for a non-current buffer. Add a new
ml_get_buf_mut() function for the mutating use-case, which can
be grepped along with the other ml_replace() etc functions which
can modify the memline.
Problem: screenpos() may cause unnecessary redraw.
Solution: Don't unnecessarily reset VALID_WROW flag.
VALID_WROW flag is only used by two functions: validate_cursor() and
cursor_valid(), and cursor_valid() is only used once in ex_sleep().
When adjust_plines_for_skipcol() was first added in patch 9.0.0640, it
was called in two functions: comp_botline() and curs_rows().
- comp_botline() is called in two places:
- onepage(), which resets VALID_WROW flag immediately afterwards.
- validate_botline_win(), where resetting a VALID_ flag is strange.
- curs_rows() is called in two places:
- curs_columns(), which sets VALID_WROW flag afterwards.
- validate_cline_row(), which is only used by GUI mouse focus.
Therefore resetting VALID_WROW there doesn't seem to do anything useful.
Also, a w_skipcol check (which resets VALID_WROW flag) was added to
check_cursor_moved() in patch 9.0.0734, which seems to make more sense
than resetting that flag in the middle of a computation.
While at it make adjust_plines_for_skipcol() and textpos2screenpos() a
bit less confusing:
- Make adjust_plines_for_skipcol() return "off" instead of "n - off".
- Use 0-based "row" in textpos2screenpos() until W_WINROW is added.
closes: vim/vim#128326235a109c4
Problem: screenpos() wrong result with w_skipcol and cpoptions+=n
Solution: Use adjust_plines_for_skipcol() instead of subtracting
w_skipcol.
closes: vim/vim#12625bfe377b8f2
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.
Problem: Line pointer becomes invalid when using spell checking.
Solution: Call ml_get() at the right places. (Luuk van Baal, closesvim/vim#12456)
e84c773d42
Problem: Weird use of static variables for spell checking.
Solution: Move the variables to a structure and pass them from win_update()
to win_line(). (Luuk van Baal, closesvim/vim#12448)
30805a1aba
Problem: SpellCap highlight not always updated when needed.
Solution: Handle updating line below closed fold and other situations where
only part of the window is redrawn. (Luuk van Baal, closesvim/vim#12428,
closesvim/vim#12420)
2ac6497f0e
Problem: Inserting lines when scrolling with 'smoothscroll' set.
Solution: Adjust line height computation for w_skipcol. (Luuk van Baal,
closesvim/vim#12350)
c8502f9b88
Problem: 'smoothscroll' not tested with 'number' and "n" in 'cpo'.
Solution: Add tests, fix uncovered problem.
b6aab8f44b
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: 'statuscolumn' width may be reset after it has been drawn
when multiple windows contain the same buffer. This results
in an offset for the drawn cursor position.
Solution: Loop over all windows (twice) prior to drawing them to
reset the 'statuscolumn' width and validate the sign
column when necessary.
Problem: After neovim/neovim@846a056, only the ruler for current floating or
last window without a statusline is drawn in the cmdline. This means that if the
current window is not one of these, but has no statusline, its ruler will not be
drawn anymore.
Solution: Make `showmode()` draw the ruler of the current window or the last
window in the cmdline if it has no statusline. This also maintains the
previously restored floating window case (`float->w_status_height` should be 0).
This behaviour should again match Vim, but without the overdraw it seems to do
to achieve the same effect; it calls `showmode()` to draw the ruler for the last
window without a statusline, then may draw over it in `showruler()` (which is
now `show_cursor_info_later()` in Nvim) to show the ruler for the current
window..? It's very confusing.
Also update the logic in `win_redr_ruler()` to mirror the check done in
`showmode()`, so that the ruler doesn't potentially draw over the long
ins-completion mode message in some cases.
extranges and a bunch of other improvements are coming for 0.10
This gets in some minor surrounding API changes to avoid rebase
conflicts until then.
- decorations will be able to be specific to windows
- adjust deletion API to fit with extranges
drawscreen.c vs screen.c makes absolutely no sense.
The screen exists only to draw upon it, therefore helper functions
are distributed randomly between screen.c and the file that
does the redrawing. In addition screen.c does a lot of drawing on the
screen.
It made more sense for vim/vim as our grid.c is their screen.c
Not sure if we want to dump all the code for option chars into
optionstr.c, so keep these in a optionchar.c for now.
Semi-regression. The "ruler" behavior for a floating window
was never really specified but in practice followed the users
cursor movements in normal mode in a focused float, which seems
like a reasonable behavior to now specify.
This fixes two clang warnings.
Using an unintialized "cursorline_fi" without assigning to it is not
something that should normally happen, and in case it happens it will
likely cause another redraw, but still don't use unintialized memory.
Problem: The cursorline highlight logic checks for `w_cursor.lnum`
which may be different from the line number passed to
`win_line()` even when the cursor is actually on that line.
Solution: Update cursor line highlight logic to check for the line
number of the start of a closed fold if necessary.
Problem:
When not inside an Ex command, screen_resize() calls update_screen(),
which calls screenclear() and set the screen as valid. However, when
inside an Ex command, redrawing is postponed so update_screen() screen
doesn't do anything, and the screen is still invalid after the resize,
causing ui_comp_raw_line() to be no-op until update_screen() is called
on the main loop.
Solution:
Restore the call to screenclear() inside screen_resize() so that the
screen is invalid after screen_resize(). Since screenclear() changes
redraw type from UPD_CLEAR to UPD_NOT_VALID, it is called at most once
for each resize, so this shouldn't change how much code is run in the
common (not inside an Ex command) case.
