| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This requires removing the "Inner expression should be aligned" rule
from clint as it prevents essentially any formatting regarding ternary
operators.
|
| |
|
|
|
| |
- reduce variable scope
- prefer initialization over declaration and assignment
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: The legacy signlist data structures and associated functions are
redundant since the introduction of extmark signs.
Solution: Store signs defined through the legacy commands in a hashmap, placed
signs in the extmark tree. Replace signlist associated functions.
Usage of the legacy sign commands should yield no change in behavior with the
exception of:
- "orphaned signs" are now always removed when the line it is placed on is
deleted. This used to depend on the value of 'signcolumn'.
- It is no longer possible to place multiple signs with the same identifier
in a single group on multiple lines. This will now move the sign instead.
Moreover, both signs placed through the legacy sign commands and through
|nvim_buf_set_extmark()|:
- Will show up in both |sign-place| and |nvim_buf_get_extmarks()|.
- Are displayed by increasing sign identifier, left to right.
Extmark signs used to be ordered decreasingly as opposed to legacy signs.
|
| |
|
|
|
|
|
| |
We already have an extensive suite of static analysis tools we use,
which causes a fair bit of redundancy as we get duplicate warnings. PVS
is also prone to give false warnings which creates a lot of work to
identify and disable.
|
| |
|
|
|
|
| |
long is 32 bits on windows, while it is 64 bits on other architectures.
This makes the type suboptimal for a codebase meant to be
cross-platform. Replace it with more appropriate integer types.
|
| |
|
|
|
| |
Uncrustify is the source of truth where possible.
Remove any redundant checks from clint.py.
|
| |
|
|
|
|
| |
long is 32 bits on windows, while it is 64 bits on other architectures.
This makes the type suboptimal for a codebase meant to be
cross-platform. Replace it with more appropriate integer types.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |\
| |
| | |
refactor(options)!: graduate shortmess+=f flag
|
| | |
| |
| |
| |
| |
| |
| | |
Not everything needs to be crazy overconfigurable.
Also fixes a warning in latest clang which didn't approve of
the funky math switch statement in append_arg_number
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: Functions for virtcol and chartabsize are similar (both compute
horizontal size), but appear in two different source files.
Solution: Move virtcol functions to plines.c.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
long is 32-bits even on 64-bit windows which makes the type suboptimal
for a codebase meant to be cross-platform.
|
| | |
|
| | |
|
| |
|
|
| |
Use the actual width of the 'statuscolumn' to allocate and fill its click definition array.
The returned width of the built statuscolumn string may be shorter (and is padded later).
|
| |
|
|
| |
(#23823)
|
| |
|
|
| |
Adds new API helper macros `CSTR_AS_OBJ()`, `STATIC_CSTR_AS_OBJ()`, and `STATIC_CSTR_TO_OBJ()`, which cleans up a lot of the current code. These macros will also be used extensively in the upcoming option refactor PRs because then API Objects will be used to get/set options. This PR also modifies pre-existing code to use old API helper macros like `CSTR_TO_OBJ()` to make them cleaner.
|
| | |
|
| |
|
|
| |
Notable changes: replace all infinite loops to `while(true)` and remove
`int` from `unsigned int`.
|
| |
|
|
|
|
|
|
|
|
| |
In file included from /usr/include/string.h:535,
from gsrc/nvim/statusline.c:10:
In function ‘strcat’,
inlined from ‘build_stl_str_hl’ at gsrc/nvim/statusline.c:1688:9:
/usr/include/bits/string_fortified.h:130:10: warning: ‘p’ may be used uninitialized [-Wmaybe-uninitialized]
130 | return __builtin___strcat_chk (__dest, __src, __glibc_objsize (__dest));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: Ruler not drawn correctly when using 'rulerformat'.
Solution: Adjust formatting depending on whether the ruler is drawn in the
statusline or the command line. (Sean Dewar, closes vim/vim#12246)
https://github.com/vim/vim/commit/fc8a601c3251c0388a88c1235b18c529385f7196
This issue was made apparent after neovim/neovim@0f1e2b6, as `showmode()` calls
`win_redr_ruler()` with `curwin` now if it's floating, rather than the last
window if there's no statusline (which usually already shares its right side
with that of the editor).
Co-authored-by: Sean Dewar <seandewar@users.noreply.github.com>
|
| |
|
|
|
|
|
|
| |
Problem: Invalid memory access with bad 'statusline' value.
Solution: Avoid going over the NUL at the end.
https://github.com/vim/vim/commit/7b17eb4b063a234376c1ec909ee293e42cff290c
Co-authored-by: Bram Moolenaar <Bram@vim.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: Vim9: leaking memory when using continuation line.
Solution: Keep a pointer to the continuation line in evalarg_T. Centralize
checking for a next command.
https://github.com/vim/vim/commit/b171fb179053fa631fec74911b5fb9374cb6a8a1
Omit eval_next_line(): Vim9 script only.
vim-patch:8.2.1050: missing change in struct
Problem: Missing change in struct.
Solution: Add missing change.
https://github.com/vim/vim/commit/65a8ed37f7bc61fbe5c612a7b0eb0dfc16ad3e11
Co-authored-by: Bram Moolenaar <Bram@vim.org>
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
* fix(column): rebuild status column when sign column is invalidated
Problem: When implementing a custom sign column through
`'statuscolumn'`, the status column is not properly rebuilt
when the sign column width changes.
Solution: Force a rebuild of the status column when the sign column
width is invalidated.
* test(column): 'statuscolumn' has correct width when (un)placing signs
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Problem: 'statusline'-format UI elements are redrawn on each K_EVENT.
Solution: Only redraw UI elements when something relevant has changed.
|
| |\
| |
| | |
custom statusline crash containing unprintable unicode
|
| | | |
|
| |\ \
| | |
| | | |
fix(column): no longer reset nrwidth_line_count for 'statuscolumn'
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Problem: `build_statuscol_str()` still has arguments that were
necessary for building a status column string in
`number_width()`, which was abandoned in #22094.
Solution: Remove unused arguments.
|
| |\ \ \
| |_|/
|/| | |
perf(column): only build fold/sign column when present in 'statuscolumn'
|
