| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
decor->text.str pointer must go. This removes it for conceal char,
in preparation for a larger PR which will also handle the sign case.
By actually allowing composing chars for a conceal chars, this
becomes a feature and not just a refactor, as a bonus.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This requires removing the "Inner expression should be aligned" rule
from clint as it prevents essentially any formatting regarding ternary
operators.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
Note: The crash happens in the second test case when using uninitialized
memory, and therefore doesn't happen with ASAN.
|
| | |
|
| |
|
|
|
| |
Uncrustify is the source of truth where possible.
Remove any redundant checks from clint.py.
|
| |
|
|
|
|
|
|
|
|
| |
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`
|
| | |
|
| | |
|
| |\
| |
| | |
feat(ui): allow to get the highlight namespace. closes #24390
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
- 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
|
| |/ |
|
| |
|
|
|
| |
problem: there are too many different functions in message.c
solution: fold some of the functions into themselves
|
| |\
| |
| | |
fix(highlight): add force in nvim_set_hl
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
fix #24699
fix #25253
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |\
| |
| | |
feat(msgpack_rpc): add a new `msgpack-rpc` client type to fix behavior with MessagePack-RPC compliant clients
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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#12699
closes: vim/vim#12697
https://github.com/vim/vim/commit/7e0bae024d4c1673cff31763227ad52b936fa56f
|
| |
|
|
|
| |
Initially this is just for geting rid of boilerplate,
but eventually the types could get exposed as metadata
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
related: 21eacbfef399
|
| |
|
|
|
|
|
|
|
|
|
| |
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).
|
| | |
|
| |
|
|
|
| |
Close #18907
Close #20314
Close #23749
|
| | |
|
| |
|
|
| |
closes #19198
|
