| Commit message (Collapse) | Author | Age |
| ... | |
| | |
| |
| |
| |
| |
| |
| |
| | |
The details are in the on-line help under :help true-color .
The brief precis is that nvim is (I hope.) converging with tmux and libvte.
It is taking the same approach with setrgbf and setrgbb terminfo capabilities
that it does with the Ss and Se terminfo capabilities.
|
| | |
| |
| |
| |
| | |
No change to their contents, but make the Big Blocks Of Numbers half as wide
but twice as deep, in order to accomodate house style.
|
| | |
| |
| |
| |
| | |
Replace the 8-color xterm from unibilium with the 256-colour one from terminfo.
Add a fallback record for suckless terminal.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
The details are in the on-line help under :help cursor-shape .
The brief precis is that nvim is following the lead of tmux, and going
beyond what tmux does to make cursor shape changes work on a broad range of
terminals. This includes on tmux itself, which is no longer bypassed.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There are now a few built-in terminfo entries, taken either from unibilium
or ncurses terminfo, for falling back upon when there is no terminfo database
or when it is missing stuff. In an ideal world, these would be in unibilium
itself.
The ultimate fallback, for no terminfo database and no built-in terminfo
record that matches the terminal type, is now the "ansi" terminal type; so
unknown terminal types are now considered to have at minimum the basic
ECMA-48 colour, motion, and editing capabilities.
The terminfo records are just blobs, raw images of the equivalent terminfo file
created with the od command. No longer are incomplete terminfo records built
up with code. These blobs are the full, real, records; already built.
The post-processing of the terminfo record, once found, is split into the
part where we fix known errors and deficiencies in terminfo, and the part
where we add extensions that we need that terminfo does not define
capabilities for. In an ideal world, the former would be a no-op.
No part of the TUI layer apart from these is aware of terminal type or has
conditional code based upon checking environment variables at runtime. It
is all pre-calculated and written into unibilium (or the TUIData object) at
initialization time.
This is fairly aggressive about turning on 256-colour and true colour support.
This also positively decodes genuine xterm for turning on DECSLRM use, rather
than assuming that anything that says that it is xterm is actually xterm,
fixing scrolling problems with vertically split windows.
|
| | |
| |
| |
| |
| | |
The clear_screen capability moves the cursor position.
This needs to be accounted for.
|
| | |
| |
| |
| | |
Per warnings about house style from automated tools.
|
| | |
| |
| |
| | |
A slight improvement on the CR optimization for some edge cases.
|
| | |
| |
| |
| |
| |
| | |
PuTTY does not implement DECLRMM or DECSLRM, but it does implement DECSTBM.
So allow using PuTTY terminal scrolling when the scroll rectangle is the
full width of the terminal.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Instead of emitting CUP in several places each with their own poor local
optimizations, funnel all cursor motion through a central place.
This central function performs the same optimization for every place that
needs to move the cursor, and implements a better set of optimizations:
* Emit CUU/CUD/CUF/CUB instad of CUP when they are likely shorter.
* Use BS and LF when they are shorter than CUB and CUD.
* Use CR for quick returns to column zero.
* If printing the next few characters is shorter than a rightwards motion,
then just write out the characters.
|
| | |
| |
| |
| |
| | |
Track whether the terminal is in no attribute mode, assuming that it starts
this way, and do not attempt to reset back to that mode if already in it.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
... rather than hardwiring the string and testing the terminal
type every time the screen is re-sized.
|
| | |
| |
| |
| |
| |
| | |
Respect the BGE flag from terminfo rather than guessing that it is
always off. Emit DECLRMM and DECSLRM (or equivalent) to properly define
the scroll rectangle.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
DECSLPP is explicitly documented as not affecting the scroll region. The
dtterm extension is not as well documented, but it is safer than not to
assume that it operates similarly.
This also eliminates a pointlessly repeated test from tui_scroll(). It
additionally uses a non-parameterized DECSTBM sequence when attempting
to reset back to whole-screen scrolling.
|
| | |
| |
| |
| |
| | |
... rather than hardwiring the string and testing the terminal
type every time the screen is re-sized.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This limits the use of dtterm's extension to DECSLPP to only those
terminal types where it is known to be supported.
Because it can be potentially understood as genuine DECSLPP
sequence, setting the number of lines to a number larger than 25,
which of course can cause confusion (especially if it is the width
parameter that results in this) only use it on terminals that are
known to support the dtterm extension.
rxvt (Unicode) also understands dtterm's extension.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
term_input_start should be called only once. This fixes a leak
introduced by af2e629be4d20dda334a7c6ca817f5599956e4ff.
Closes #6780
Steps to demonstrate memory leak:
CC=clang CFLAGS=" -O0 -g -DEXITFREE " cmake .. -DMIN_LOG_LEVEL=0 -DCMAKE_BUILD_TYPE=Debug -DBUSTED_OUTPUT_TYPE=nvim -DCMAKE_INSTALL_PREFIX=$PWD/root -DCLANG_ASAN_UBSAN=ON -DPREFER_LUAJIT=false
nvim -u NONE -i NONE --cmd $'function S()\nsuspend\nendfunction' --cmd 'inoremap <expr> X S()' --cmd 'call feedkeys("iX", "t")'
fg<CR><Esc>:cq<CR>
```
=================================================================
==25050==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 4159 byte(s) in 1 object(s) allocated from:
#0 0x4f6a30 in calloc /var/tmp/portage/sys-devel/llvm-3.9.1-r1/work/llvm-3.9.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:72
#1 0xf8d222 in xcalloc /home/zyx/a.a/Proj/c/neovim/src/nvim/memory.c:147:15
#2 0x1349d28 in rbuffer_new /home/zyx/a.a/Proj/c/neovim/src/nvim/rbuffer.c:24:17
#3 0xa6867b in rstream_init /home/zyx/a.a/Proj/c/neovim/src/nvim/event/rstream.c:42:20
#4 0xa68651 in rstream_init_fd /home/zyx/a.a/Proj/c/neovim/src/nvim/event/rstream.c:28:3
#5 0x1866451 in term_input_init /home/zyx/a.a/Proj/c/neovim/src/nvim/tui/input.c:55:3
#6 0x187f049 in tui_terminal_start /home/zyx/a.a/Proj/c/neovim/src/nvim/tui/tui.c:223:3
#7 0x187b491 in tui_main /home/zyx/a.a/Proj/c/neovim/src/nvim/tui/tui.c:258:3
#8 0x18b3171 in ui_thread_run /home/zyx/a.a/Proj/c/neovim/src/nvim/ui_bridge.c:124:3
#9 0x7f54c2d5f39b (/lib64/libpthread.so.0+0x739b)
Direct leak of 4159 byte(s) in 1 object(s) allocated from:
#0 0x4f6a30 in calloc /var/tmp/portage/sys-devel/llvm-3.9.1-r1/work/llvm-3.9.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:72
#1 0xf8d222 in xcalloc /home/zyx/a.a/Proj/c/neovim/src/nvim/memory.c:147:15
#2 0x1349d28 in rbuffer_new /home/zyx/a.a/Proj/c/neovim/src/nvim/rbuffer.c:24:17
#3 0x1865a4a in term_input_init /home/zyx/a.a/Proj/c/neovim/src/nvim/tui/input.c:29:23
#4 0x187f049 in tui_terminal_start /home/zyx/a.a/Proj/c/neovim/src/nvim/tui/tui.c:223:3
#5 0x187b491 in tui_main /home/zyx/a.a/Proj/c/neovim/src/nvim/tui/tui.c:258:3
#6 0x18b3171 in ui_thread_run /home/zyx/a.a/Proj/c/neovim/src/nvim/ui_bridge.c:124:3
#7 0x7f54c2d5f39b (/lib64/libpthread.so.0+0x739b)
Indirect leak of 7144 byte(s) in 62 object(s) allocated from:
#0 0x4f6840 in malloc /var/tmp/portage/sys-devel/llvm-3.9.1-r1/work/llvm-3.9.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:64
#1 0x7f54c231636c (/usr/lib64/libtermkey.so.1+0x636c)
Indirect leak of 1500 byte(s) in 75 object(s) allocated from:
#0 0x4f6840 in malloc /var/tmp/portage/sys-devel/llvm-3.9.1-r1/work/llvm-3.9.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:64
#1 0x7f54c2316b34 (/usr/lib64/libtermkey.so.1+0x6b34)
Indirect leak of 704 byte(s) in 1 object(s) allocated from:
#0 0x4f6840 in malloc /var/tmp/portage/sys-devel/llvm-3.9.1-r1/work/llvm-3.9.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:64
#1 0x7f54c23129dd in _init (/usr/lib64/libtermkey.so.1+0x29dd)
Indirect leak of 520 byte(s) in 1 object(s) allocated from:
#0 0x4f6c40 in realloc /var/tmp/portage/sys-devel/llvm-3.9.1-r1/work/llvm-3.9.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:77
#1 0x7f54c2313b7c in termkey_register_keyname (/usr/lib64/libtermkey.so.1+0x3b7c)
Indirect leak of 256 byte(s) in 1 object(s) allocated from:
#0 0x4f6840 in malloc /var/tmp/portage/sys-devel/llvm-3.9.1-r1/work/llvm-3.9.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:64
#1 0x7f54c2313c3c (/usr/lib64/libtermkey.so.1+0x3c3c)
Indirect leak of 48 byte(s) in 2 object(s) allocated from:
#0 0x4f6840 in malloc /var/tmp/portage/sys-devel/llvm-3.9.1-r1/work/llvm-3.9.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:64
#1 0x7f54c2313d9e (/usr/lib64/libtermkey.so.1+0x3d9e)
Indirect leak of 40 byte(s) in 1 object(s) allocated from:
#0 0x4f6840 in malloc /var/tmp/portage/sys-devel/llvm-3.9.1-r1/work/llvm-3.9.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:64
#1 0x7f54c2316553 (/usr/lib64/libtermkey.so.1+0x6553)
Indirect leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x4f6840 in malloc /var/tmp/portage/sys-devel/llvm-3.9.1-r1/work/llvm-3.9.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:64
#1 0x7f54c2315a2f (/usr/lib64/libtermkey.so.1+0x5a2f)
Indirect leak of 8 byte(s) in 1 object(s) allocated from:
#0 0x485ca8 in __interceptor_strdup /var/tmp/portage/sys-devel/llvm-3.9.1-r1/work/llvm-3.9.1.src/projects/compiler-rt/lib/asan/asan_interceptors.cc:562
#1 0x7f54c2316bef (/usr/lib64/libtermkey.so.1+0x6bef)
Indirect leak of 8 byte(s) in 1 object(s) allocated from:
#0 0x485ca8 in __interceptor_strdup /var/tmp/portage/sys-devel/llvm-3.9.1-r1/work/llvm-3.9.1.src/projects/compiler-rt/lib/asan/asan_interceptors.cc:562
#1 0x7f54c2316c0f (/usr/lib64/libtermkey.so.1+0x6c0f)
Indirect leak of 4 byte(s) in 1 object(s) allocated from:
#0 0x4f6840 in malloc /var/tmp/portage/sys-devel/llvm-3.9.1-r1/work/llvm-3.9.1.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:64
#1 0x7f54c2316a26 (/usr/lib64/libtermkey.so.1+0x6a26)
SUMMARY: AddressSanitizer: 18574 byte(s) leaked in 149 allocation(s).
```
|
| | |
| |
| |
| |
| | |
The variable in question is initalized at the start of the function with
something non-NULL, specifically pointer to a static buffer.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The terminfo entry for linux only advertises 8 colours, but nvim tries
to make it display 16 colours anyway, resulting in erroneous SGR control
sequences for colours 8 and above. The Linux kernel terminal emulator
itself has actually understood the 256-colour control sequences since
version 4.8 and the 16-colour control sequences since version 4.9. Thus
we apply the same terminfo fixup as we apply for *xterm* and *256*, to
emit the 16-colour and 256-colour control sequences even if terminfo's
setaf and setab do not advertise them.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
For CI builds unibilium is provided through msys2 packages, and
libtermkey is built from source in third-party from equalsraf/libtermkey.
In Windows we cannot read terminal input from the stdin file descriptor,
instead use libuv's uv_tty API. It should handle key input and encoding.
The UI suspend is not implemented for Windows, because the
SIGSTP/SIGCONT do not exist in windows. Currently this is a NOOP.
Closes #3902
Closes #6640
|
| | | |
|
| | |
| |
| |
| | |
Closes #6577
|
| | |
| |
| |
| | |
It was replaced by the "child queue" concept (MultiQueue).
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Asynchronous API functions are served immediately, which means pending
input could change the state of Nvim shortly after an async API function
result is returned.
nvim_get_mode() is different:
- If RPCs are known to be blocked, it responds immediately (without
flushing the input/event queue)
- else it is handled just-in-time before waiting for input, after
pending input was processed. This makes the result more reliable
(but not perfect).
Internally this is handled as a special case, but _semantically_ nothing
has changed: API users never know when input flushes, so this internal
special-case doesn't violate that. As far as API users are concerned,
nvim_get_mode() is just another asynchronous API function.
In all cases nvim_get_mode() never blocks for more than the time it
takes to flush the input/event queue (~µs).
Note: This doesn't address #6166; nvim_get_mode() will provoke #6166 if
e.g. `d` is operator-pending.
Closes #6159
|
| | |
| |
| |
| |
| |
| | |
- Work with a bool[] array parallel to the UIWidget enum.
- Rename some functions.
- Documentation.
|
| | | |
|
| | |
| |
| | |
Closes #6584
|
| | |
| |
| |
| |
| |
| | |
Should never happen, but better to be explicit.
Helped-by: oni-link <knil.ino@gmail.com>
|
| | | |
|
| | |
| |
| |
| | |
Closes #5984
|
| | |
| |
| |
| |
| | |
iTerm uses proprietary escape codes to set cursor color.
https://www.iterm2.com/documentation-escape-codes.html
|
| |\ \ |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
throttle unneccessary cursor shape events
|
| |/ / |
|
| | |
| |
| |
| |
| | |
Closes #6429
Closes #6430
|
| | | |
|
| | |
| |
| |
| | |
Also: update default 'guicursor' to match the documentation.
|
| | |
| |
| |
| |
| |
| | |
For now only supports valid hex colors (does not check for the validity
the hex color) when termguicolors is set, otherwise it won't attempt to
change the cursor color.
|
| | |
| |
| |
| | |
Closes #2583
|
| | |
| |
| |
| |
| |
| |
| | |
If we get a mouse_on/mouse_off event, but the mouse is already in the
corresponding state, there's no need to send the event up to the
terminal.
Closes #4394
|
| | | |
|