| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Create mapping to most of the C spec and some POSIX specific functions.
This is more robust than relying files shipped with IWYU.
|
| |
|
|
| |
Nvim no longer calls loop_poll_events() when suspending, so it isn't
necessary to schedule suspend_event.
|
| |
|
|
|
|
|
| |
Enable all clang-tidy warnings by default instead of disabling them.
This ensures that we don't miss useful warnings on each clang-tidy
version upgrade. A drawback of this is that it will force us to either
fix or adjust the warnings as soon as possible.
|
| |
|
|
|
|
| |
This requires removing the "Inner expression should be aligned" rule
from clint as it prevents essentially any formatting regarding ternary
operators.
|
| |
|
|
| |
Biggest change is that uncrustify is silent during linting.
|
| |
|
|
|
| |
The sign extension issue has been fixed upstream, so we no longer need
to use our own workaround.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Refactor our implementation of querying for Kitty keyboard protocol
support:
- Remove usage of the "extkeys" term. This is not standard or really
used elsewhere. Use "key encoding" instead
- Replace usages of "CSIu" with "Kitty". "Kitty keyboard protocol" is
vastly more common than "CSIu" now
- Replace the countdown response counter with a simple boolean flag. We
don't actually need a countdown counter because we request the primary
device attributes along with the Kitty keyboard query, so we will
always receive a "terminating event", making a countdown/timer
unnecessary
- Move the CSI response handling into a dedicated function
- Bypass Unibilium for sending key encoding escape sequences. These
sequences are not part of terminfo and do not have any parameters, so
there's no reason to go through Unibilium
|
| |
|
|
| |
The test is for the case without 'termsync' because libvterm doesn't
support synchronized output, and it passes without this PR.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When writing large amounts of data to the tty it is common to first hide
the cursor to avoid a flickering effect. This has been done in Nvim for
a long time and was implemented in the function that actually flushed
the TUI buffer out to the TTY.
However, when using synchronized updates with the 'termsync' option this
is no longer necessary, as the terminal emulator will buffer all of the
updates and display them atomically. Thus there is no need to toggle the
cursor visibility when flushing the buffer when synchronized updates are
used. In fact, doing so can actually reintroduce cursor flickering in
certain scenarios because the visibility state is itself being
synchronized by the terminal.
In addition, the management of the cursor visibility should not happen
when the TUI _buffer_ is flushed, but rather when the TUI itself is
flushed. This is a subtle but meaningful distinction: the former
literally writes bytes to the TTY while the latter flushes the TUI's
grid into its buffer. There is no need to hide the cursor every time we
write bytes to the TTY, only at the beginning of a full TUI "flush"
event.
|
| |
|
|
|
|
|
| |
The 'termsync' option enables a mode (provided the underlying terminal
supports it) where all screen updates during a redraw cycle are buffered
and drawn together when the redraw is complete. This eliminates tearing
or flickering in cases where Nvim redraws slower than the terminal
redraws the screen.
|
| | |
|
| |
|
|
|
| |
It is less error-prone than manually defining header guards. Pretty much
all compilers support it even if it's not part of the C standard.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
This ensures that the read stream never overflows termkey's internal
buffer. This only happens when a large amount of bytes are pushed into
termkey at the same time, which is exactly what happens when we receive
a large OSC 52 response.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When the terminal emulator sends an OSC sequence to Nvim (as a response
to another OSC sequence that was first sent by Nvim), populate the OSC
sequence in the v:termresponse variable and fire the TermResponse event.
The escape sequence is also included in the "data" field of the
autocommand callback when the autocommand is defined in Lua.
This makes use of the already documented but unimplemented TermResponse
event. This event exists in Vim but is only fired when Vim receives a
primary device attributes response.
Fixes: https://github.com/neovim/neovim/issues/25856
|
| |
|
|
|
|
| |
Problem: The style guide states that all switch statements that are not conditional on an enum must have a `default` case, but does not give any explicit guideline for switch statements that are conditional on enums. As a result, a `default` case is added in many enum switch statements, even when the switch statement is exhaustive. This is not ideal because it removes the ability to have compiler errors to easily detect unchanged switch statements when a new possible value for an enum is added.
Solution: Add explicit guidelines for switch statements that are conditional on an enum, clarifying that a `default` case is not necessary if the switch statement is exhaustive. Also refactor pre-existing code with unnecessary `default` cases.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
- 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
|
| | |
|
| |
|
|
|
| |
long is 32-bits even on 64-bit windows which makes the type suboptimal
for a codebase meant to be cross-platform.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If nvim exited with nonzero status this is for one of the two reasons
- `:cquit` was invoked. This is used by users and plugins to communicate
a result, like a nonzero status will fail a `git commit` operation
- There was an internal error or deadly signal. in this case an error
message was likely written to stderr or to the screen.
In the latter case, the error message was often hidden by the TUI
exiting altscreen mode, which erases all visible terminal text.
This change prevents this in the latter case, while still cleaning up
the terminal properly when `:cquit` was deliberatily invoked.
Other cleanup like exiting mouse mode and raw mode is still done.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This involves two redesigns of the map.c implementations:
1. Change of macro style and code organization
The old khash.h and map.c implementation used huge #define blocks with a
lot of backslash line continuations.
This instead uses the "implementation file" .c.h pattern. Such a file is
meant to be included multiple times, with different macros set prior to
inclusion as parameters. we already use this pattern e.g. for
eval/typval_encode.c.h to implement different typval encoders reusing a
similar structure.
We can structure this code into two parts. one that only depends on key
type and is enough to implement sets, and one which depends on both key
and value to implement maps (as a wrapper around sets, with an added
value[] array)
2. Separate the main hash buckets from the key / value arrays
Change the hack buckets to only contain an index into separate key /
value arrays
This is a common pattern in modern, state of the art hashmap
implementations. Even though this leads to one more allocated array, it
is this often is a net reduction of memory consumption. Consider
key+value consuming at least 12 bytes per pair. On average, we will have
twice as many buckets per item.
Thus old implementation:
2*12 = 24 bytes per item
New implementation
1*12 + 2*4 = 20 bytes per item
And the difference gets bigger with larger items.
One might think we have pulled a fast one here, as wouldn't the average size of
the new key/value arrays be 1.5 slots per items due to amortized grows?
But remember, these arrays are fully dense, and thus the accessed memory,
measured in _cache lines_, the unit which actually matters, will be the
fully used memory but just rounded up to the nearest cache line
boundary.
This has some other interesting properties, such as an insert-only
set/map will be fully ordered by insert only. Preserving this ordering
in face of deletions is more tricky tho. As we currently don't use
ordered maps, the "delete" operation maintains compactness of the item
arrays in the simplest way by breaking the ordering. It would be
possible to implement an order-preserving delete although at some cost,
like allowing the items array to become non-dense until the next rehash.
Finally, in face of these two major changes, all code used in khash.h
has been integrated into map.c and friends. Given the heavy edits it
makes no sense to "layer" the code into a vendored and a wrapper part.
Rather, the layered cake follows the specialization depth: code shared
for all maps, code specialized to a key type (and its equivalence
relation), and finally code specialized to value+key type.
|
| |
|
|
|
|
|
| |
Counterintuitively, snprintf returns the number of characters it _should
have written_ if it had not encoutered the length bound, thus leading to
a potential buffer overflow.
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
|
| | |
|
| | |
|
| |
|
|
| |
Since title stack is now saved after entering alternate screen, it makes
more sense to restore title before exiting alternate screen.
|
| |
|
|
| |
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.
|
| |
|
|
| |
This makes setting 'notitle' in Nvim behave more like Vim in terminals
that support title stacking.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reduces the total number of khash_t instantiations from 22 to 8.
Make the khash internal functions take the size of values as a runtime
parameter. This is abstracted with typesafe Map containers which
are still specialized for both key, value type.
Introduce `Set(key)` type for when there is no value.
Refactor shada.c to use Map/Set instead of khash directly.
This requires `map_ref` operation to be more flexible.
Return pointers to both key and value, plus an indicator for new_item.
As a bonus, `map_key` is now redundant.
Instead of Map(cstr_t, FileMarks), use a pointer map as the FileMarks struct is
humongous.
Make `event_strings` actually work like an intern pool instead of wtf it
was doing before.
|
| |\
| |
| | |
fix(tui): redraw on SIGWINCH even if size didn't change
|
| | | |
|
| |/
|
|
|
|
|
| |
Problem: When setting a shell size smaller than the containing
terminal window through `:winsize` or `:set lines/columns`
the screen is not properly cleared.
Solution: Clear the tui dimensions rather than the grid dimensions.
|
| |
|
| |
Fix #23361
|
| |
|
|
| |
Notable changes: replace all infinite loops to `while(true)` and remove
`int` from `unsigned int`.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
