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.
Problem:
The next command after `silent !{cmd}` or `silent lua print('str')`
prints an empty line before printing a message, because these commands
set `msg_didout = true` despite not printing any messages.
Solution:
Set `msg_didout = true` only if `msg_silent == 0`
- 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
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.
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.
Problem: mapset() not properly handling script ID
Solution: replace_termcodes() may accept a script ID
closes: vim/vim#12699closes: vim/vim#126977e0bae024d
Problem: As discussed on Matrix, there was some interest in having
`nvim_open_win` again be able to open floats in the cmdwin (e.g: displaying a
hover doc related to what's in the cmdwin). After #23228, this was disallowed.
Solution: Allow `nvim_open_win` in the cmdwin as long as `!enter` and
`buffer != curbuf` (the former can cause all sorts of issues, and the latter
can crash Nvim after closing cmdwin). Also allow `nvim_win_set_buf` in a similar
fashion.
Note that we're not *entirely* sure if this is 100% safe (cmdwin is a
global-state-using-main-loop-calling beast), but this seems to work OK..?
Also:
- Check the buffer argument of `nvim_open_win` earlier, and abort if it's
invalid (it used to still open a window in this case).
- Untranslate `e_cmdwin` errors in the API (other errors in the API are not
translated: although not detailed in the API contract yet, errors are
supposed to be stable).
* perf(rtp): reduce rtp scans
Problem:
Scanning the filesystem is expensive and particularly affects
startuptime.
Solution:
Reduce the amount of redundant directory scans by relying less on glob
patterns and handle vim and lua sourcing lower down.
Problem:
Lua functions that return multiple results are declared by using
multiple `@return` docstring directives. But the generated docs don't
make it obvious what this represents.
Solution:
- Generate a "Return (multiple)" heading for multiple-value functions.
- Fix `@note` directives randomly placed after `@return`.
Problem: nvim_buf_set_text(), nvim_open_term() and termopen() all change buffer
text, which is forbidden during textlock. Additionally, nvim_open_term() and
termopen() may be used to convert the cmdwin buffer into a terminal buffer,
which is weird.
Solution: Allow nvim_buf_set_text() and nvim_open_term() in the cmdwin, but
disallow nvim_open_term() from converting the cmdwin buffer into a terminal
buffer. termopen() is not allowed in the cmdwin (as it always operates on
curbuf), so just check text_locked().
Also happens to improve the error in #21055: nvim_buf_set_text() was callable
during textlock, but happened to check textlock indirectly via u_save();
however, this caused the error to be overwritten by an unhelpful "Failed to
save undo information" message when msg_list == NULL (e.g: an `<expr>` mapping
invoked outside of do_cmdline()).
Problem: some API functions that check textlock (usually those that can change
curwin or curbuf) can break the cmdwin.
Solution: make FUNC_API_CHECK_TEXTLOCK call text_locked() instead, which already
checks for textlock, cmdwin and `<expr>` status.
Add FUNC_API_TEXTLOCK_ALLOW_CMDWIN to allow such functions to be usable in the
cmdwin if they can work properly there; the opt-in nature of this attribute
should hopefully help mitigate future bugs.
Also fix a regression in #22634 that made functions checking textlock usable in
`<expr>` mappings, and rename FUNC_API_CHECK_TEXTLOCK to FUNC_API_TEXTLOCK.
Enforce consistent terminology (defined in
`gen_help_html.lua:spell_dict`) for common misspellings.
This does not spellcheck English in general (perhaps a future TODO,
though it may be noisy).
Removes the `getoption_T` struct and also introduces the `OptVal` struct
to unify the methods of getting/setting different option value types.
This is the first of many PRs to reduce code duplication in the Vim
option code as well as to make options easier to maintain. It also
increases the flexibility and extensibility of options. Which opens the
door for things like Array and Dictionary options.
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.
gsrc/nvim/api/vim.c: In function ‘nvim_eval_statusline’:
gsrc/nvim/api/vim.c:2268:55: warning: ‘%d’ directive output may be truncated writing between 1 and 10 bytes into a region of size 2 [-Wformat-tru
ncation=]
2268 | snprintf(user_group, sizeof(user_group), "User%d", sp->userhl);
| ^~
gsrc/nvim/api/vim.c:2268:50: note: directive argument in the range [1, 2147483647]
2268 | snprintf(user_group, sizeof(user_group), "User%d", sp->userhl);
| ^~~~~~~~
In file included from /usr/include/stdio.h:906,
from gsrc/nvim/api/vim.c:9:
In function ‘snprintf’,
inlined from ‘nvim_eval_statusline’ at gsrc/nvim/api/vim.c:2268:9:
/usr/include/bits/stdio2.h:54:10: note: ‘__builtin___snprintf_chk’ output between 6 and 15 bytes into a destination of size 6
54 | return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
55 | __glibc_objsize (__s), __fmt,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
56 | __va_arg_pack ());
| ~~~~~~~~~~~~~~~~~
Problem: `w_scwidth` may be outdated in `nvim_eval_status()`, causing
`build_stl_str_hl()` to return an empty `%s` sign segment.
Solution: Update `w_scwidth` for `'statuscolumn'` evaluation.
Having the user set `v:lnum` before calling `nvim_eval_statusline()` is
unnecesarily fragile. Redraws inbetween setting `v:lnum` and the
`nvim_eval_statusline()` call will overwrite `v:lnum`.
