aboutsummaryrefslogtreecommitdiff
path: root/src/nvim/tui
Commit message (Collapse)AuthorAge
* Merge #8218 'Fix errors reported by PVS'Justin M. Keyes2018-04-27
|\ | | | | closes #4983
| * *: Fix clint errorsZyX2018-04-22
| |
| * tui: Silence PVS/V560: condition is set to true in prev-previous if()ZyX2018-04-22
| |
* | tui/input.c: add support for mouse release events in urxvt (#8309)symphorien2018-04-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some terminals don't report which buttons are involved in some mouse events. For example, the urxvt protocol (http://www.huge-man-linux.net/man7/urxvt.html section "Mouse reporting") does not report which button has been released. In this case libtermkey reports button 0 (http://www.leonerd.org.uk/code/libtermkey/doc/termkey_interpret_mouse.3.html) Up to now, forward_mouse_event did not handle button==0. On press events there is not much we can do, and we keep the current behavior which is dropping the event. But on drag-and-release events we can compensate by remembering the last button pressed. fixes #3182 for urxvt fixes #5400
* | tui: abort on unexpected enum value (#8266)John Szakmeister2018-04-13
| | | | | | ref #8261
* | tui: fix uninitialize variable usage (#8261)John Szakmeister2018-04-12
| | | | | | | | | | This fixes an issue with compiles failing in release mode due to shape having the possibility of being used uninitialized (since the default case was missing).
* | build/clang 6.0.0: fix type conversion warnings (#8235)Marco Hinz2018-04-07
| |
* | TUI: EMSG2 must not be used from TUI threadBjörn Linse2018-04-06
|/
* TUI: implement "standout" attribute #8081Nimit Bhardwaj2018-03-27
| | | | closes #8054
* ui_bridge: make sure TUI receives no more UI events after "stop" eventBjörn Linse2018-02-22
|
* ui/tui: highlighting refactorBjörn Linse2018-02-11
| | | | | | | | Make HlAttr contain highlighting state for both color modes (cterm and rgb). This allows us to implement termguicolors completely in the TUI. Simplify some logic duplicated between ui.c and screen.c. Also avoid some superfluous highlighting reset events.
* tui: libtermkey: force CSI driver for mouse input #7948Chih-Hsuan Yen2018-01-31
| | | | | | | | | | | | | | | | | | Fixes #7932 Nvim (tui.c) always enables SGR mouse (TUIData.unibi_ext.enable_mouse). But if libtermkey sees key_mouse (kmous) in terminfo its terminfo driver (driver-ti.c) will be activated, which by accident only supports X10 protocol. The libtermkey CSI driver (driver-csi.c), in contrast, supports SGR. We can force libtermkey to ignore the terminfo key_mouse entry by returning NULL in the tui_tk_ti_getstr hook. That forces the CSI driver. What is the effect of returning NULL from `tui_tk_ti_getstr()`? - libtermkey `driver-ti.c:load_terminfo()` skips the entry. - `termkey.c:peekkey()` iterates through all drivers, it finds `TERMKEY_RES_NONE` for the ti driver and falls back to the CSI driver.
* tui: fix use-after-free after UI `stop` event #7922Justin M. Keyes2018-01-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ui_bridge:ui_bridge_stop() calls ui_detach_impl() last, so the check for ui_active() in ui:ui_refresh() doesn't help: tui_main() already freed the `ui` object. There is a race between ui_bridge_stop (thread T0) and tui_main (thread T1). UIBridgeData.stopped could be set while ui_bridge_stop() is in the middle of loop_poll_events(), which may invoke tui_scheduler() on T0. The pointers in tui_scheduler() may be invalid by then. Solution(?): Use the `UI.data` field as a "stopped" flag and check it in tui_scheduler(). ASAN use-after-free report observed in #7908: = ==20066==ERROR: AddressSanitizer: heap-use-after-free on address 0x611000000cd0 at pc 0x00000182abed bp 0x7ffe23b07070 sp 0x7ffe23b07068 = READ of size 8 at 0x611000000cd0 thread T0 = 0 0x182abec in tui_scheduler /home/travis/build/neovim/neovim/src/nvim/tui/tui.c:393:23 = 1 0x1876afd in ui_bridge_update_fg /home/travis/build/neovim/neovim/build/src/nvim/auto/ui_events_bridge.generated.h:205:3 = 2 0x186c130 in ui_resize /home/travis/build/neovim/neovim/src/nvim/ui.c:310:3 = 3 0x146b9c2 in screen_resize /home/travis/build/neovim/neovim/src/nvim/screen.c:7483:3 = 4 0x186a6f0 in ui_refresh /home/travis/build/neovim/neovim/src/nvim/ui.c:284:3 = 5 0x186bbe0 in ui_refresh_event /home/travis/build/neovim/neovim/src/nvim/ui.c:297:3 = 6 0xa2219a in multiqueue_process_events /home/travis/build/neovim/neovim/src/nvim/event/multiqueue.c:150:7 = 7 0xa1bd7f in loop_poll_events /home/travis/build/neovim/neovim/src/nvim/event/loop.c:63:3 = 8 0x1872709 in ui_bridge_stop /home/travis/build/neovim/neovim/src/nvim/ui_bridge.c:121:5 = 9 0x1864247 in ui_builtin_stop /home/travis/build/neovim/neovim/src/nvim/ui.c:143:3 = 10 0x1249ec8 in mch_exit /home/travis/build/neovim/neovim/src/nvim/os_unix.c:140:3 = 11 0xe56ba9 in getout /home/travis/build/neovim/neovim/src/nvim/main.c:671:3 = 12 0xfc4c8f in preserve_exit /home/travis/build/neovim/neovim/src/nvim/misc1.c:2653:3 = 13 0x1247c02 in deadly_signal /home/travis/build/neovim/neovim/src/nvim/os/signal.c:137:3 = 14 0x1247921 in on_signal /home/travis/build/neovim/neovim/src/nvim/os/signal.c:162:9 = 15 0xa35618 in signal_event /home/travis/build/neovim/neovim/src/nvim/event/signal.c:47:3 = 16 0xa2219a in multiqueue_process_events /home/travis/build/neovim/neovim/src/nvim/event/multiqueue.c:150:7 = 17 0xa1bd7f in loop_poll_events /home/travis/build/neovim/neovim/src/nvim/event/loop.c:63:3 = 18 0x1237bd6 in input_poll /home/travis/build/neovim/neovim/src/nvim/os/input.c:349:3 = 19 0x123334f in inbuf_poll /home/travis/build/neovim/neovim/src/nvim/os/input.c:372:24 = 20 0x123316d in os_inchar /home/travis/build/neovim/neovim/src/nvim/os/input.c:110:19 = 21 0x170d20e in state_enter /home/travis/build/neovim/neovim/src/nvim/state.c:55:13 = 22 0xbd7441 in command_line_enter /home/travis/build/neovim/neovim/src/nvim/ex_getln.c:384:3 = 23 0xbd0a60 in getcmdline /home/travis/build/neovim/neovim/src/nvim/ex_getln.c:1920:10 = 24 0xbdb365 in getexline /home/travis/build/neovim/neovim/src/nvim/ex_getln.c:2100:10 = 25 0xb00a6b in do_cmdline /home/travis/build/neovim/neovim/src/nvim/ex_docmd.c:528:47 = 26 0x10a7837 in nv_colon /home/travis/build/neovim/neovim/src/nvim/normal.c:4552:18 = 27 0x1091e15 in normal_execute /home/travis/build/neovim/neovim/src/nvim/normal.c:1136:3 = 28 0x170d439 in state_enter /home/travis/build/neovim/neovim/src/nvim/state.c:67:26 = 29 0x104ee14 in normal_enter /home/travis/build/neovim/neovim/src/nvim/normal.c:466:3 = 30 0xe4295c in main /home/travis/build/neovim/neovim/src/nvim/main.c:572:3 = 31 0x2b2ba340bf44 in __libc_start_main /build/eglibc-ripdx6/eglibc-2.19/csu/libc-start.c:287 = 32 0x44d24b in _start (/home/travis/build/neovim/neovim/build/bin/nvim+0x44d24b) = = 0x611000000cd0 is located 16 bytes inside of 240-byte region [0x611000000cc0,0x611000000db0) = freed by thread T1 here: = 0 0x4ee0e2 in __interceptor_free /local/mnt/workspace/tmp/ubuntu_rel/llvm/utils/release/final/llvm.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:47:3 = 1 0xf4f6d4 in xfree /home/travis/build/neovim/neovim/src/nvim/memory.c:133:3 = 2 0x182a963 in tui_main /home/travis/build/neovim/neovim/src/nvim/tui/tui.c:383:3 = 3 0x18792b0 in ui_thread_run /home/travis/build/neovim/neovim/src/nvim/ui_bridge.c:106:3 = 4 0x2b2ba2697183 in start_thread /build/eglibc-ripdx6/eglibc-2.19/nptl/pthread_create.c:312 = = previously allocated by thread T0 here: = 0 0x4ee61a in calloc /local/mnt/workspace/tmp/ubuntu_rel/llvm/utils/release/final/llvm.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:76:3 = 1 0xf4f787 in xcalloc /home/travis/build/neovim/neovim/src/nvim/memory.c:147:15 = 2 0x182000a in tui_start /home/travis/build/neovim/neovim/src/nvim/tui/tui.c:127:12 = 3 0x1863f7c in ui_builtin_start /home/travis/build/neovim/neovim/src/nvim/ui.c:125:3 = 4 0xe41bb9 in main /home/travis/build/neovim/neovim/src/nvim/main.c:457:5 = 5 0x2b2ba340bf44 in __libc_start_main /build/eglibc-ripdx6/eglibc-2.19/csu/libc-start.c:287 = = Thread T1 created by T0 here: = 0 0x4d774d in __interceptor_pthread_create /local/mnt/workspace/tmp/ubuntu_rel/llvm/utils/release/final/llvm.src/projects/compiler-rt/lib/asan/asan_interceptors.cc:317:3 = 1 0x1aae6b0 in uv_thread_create /home/travis/nvim-deps/build/src/libuv/src/unix/thread.c:75 = 2 0x18217fa in tui_start /home/travis/build/neovim/neovim/src/nvim/tui/tui.c:159:10 = 3 0x1863f7c in ui_builtin_start /home/travis/build/neovim/neovim/src/nvim/ui.c:125:3 = 4 0xe41bb9 in main /home/travis/build/neovim/neovim/src/nvim/main.c:457:5 = 5 0x2b2ba340bf44 in __libc_start_main /build/eglibc-ripdx6/eglibc-2.19/csu/libc-start.c:287 --- Alternative attempt: commit 6ad9c02491606a0c31e907f38c9931f324327aa5 Author: Justin M. Keyes <justinkz@gmail.com> Date: Sat Jan 27 15:12:58 2018 +0100 tui: fix use-after-free: swap in empty scheduler This should make life easier for UIs like VimR which implement their own in-process bridged UI: they don't need to worry that their `scheduler` might receive an invalid pointer. To avoid that, ui_bridge_stopped() swaps in an empty scheduler. Note that this requires the call to loop_poll_events() to be moved into the critical section. diff --git a/src/nvim/ui_bridge.c b/src/nvim/ui_bridge.c index 779585416f80..491052d19d3b 100644 --- a/src/nvim/ui_bridge.c +++ b/src/nvim/ui_bridge.c @@ -93,10 +93,18 @@ UI *ui_bridge_attach(UI *ui, ui_main_fn ui_main, event_scheduler scheduler) return &rv->bridge; } +static void ui_bridge_null_scheduler(Event event, void *d) +{ + WLOG("ignoring event (bridge stopped)"); +} + void ui_bridge_stopped(UIBridgeData *bridge) { uv_mutex_lock(&bridge->mutex); bridge->stopped = true; + // Replace with an empty scheduler, so that the UI internal scheduler does + // not get invoked with an invalid pointer. #7922 + bridge->scheduler = ui_bridge_null_scheduler; uv_mutex_unlock(&bridge->mutex); } @@ -111,14 +119,11 @@ static void ui_bridge_stop(UI *b) UIBridgeData *bridge = (UIBridgeData *)b; bool stopped = bridge->stopped = false; UI_BRIDGE_CALL(b, stop, 1, b); - for (;;) { + while (!stopped) { uv_mutex_lock(&bridge->mutex); stopped = bridge->stopped; - uv_mutex_unlock(&bridge->mutex); - if (stopped) { - break; - } loop_poll_events(&main_loop, 10); // Process one event (at most). + uv_mutex_unlock(&bridge->mutex); } uv_thread_join(&bridge->ui_thread); uv_mutex_destroy(&bridge->mutex);
* Fix for lintGeorge Zhao2018-01-19
|
* Fix bug, use &loop->uv replace loop.George Zhao2018-01-18
|
* Fix warning when assing size_t type value to uv_buf_t.len, convert type to ↵George Zhao2018-01-18
| | | | ULONG on Windows.
* Fix warning about conversion on mingw64George Zhao2018-01-18
|
* tui: final_column_wrap(): fix row calculationJustin M. Keyes2018-01-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | closes #7572 closes #7579 closes #7628 ASAN report: ==9500==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6040000024c0 at pc 0x00000187d2ca bp 0x7fc3c6e58d10 sp 0x7fc3c6e58d08 READ of size 8 at 0x6040000024c0 thread T1 0 0x187d2c9 in ugrid_put /home/vagrant/neovim/build/../src/nvim/ugrid.c:107:17 1 0x1850adf in tui_put /home/vagrant/neovim/build/../src/nvim/tui/tui.c:1012:10 2 0x18a6ce6 in ui_bridge_put_event /home/vagrant/neovim/build/src/nvim/auto/ui_events_bridge.generated.h:154:3 3 0xa4dcda in multiqueue_process_events /home/vagrant/neovim/build/../src/nvim/event/multiqueue.c:150:7 4 0xa478bf in loop_poll_events /home/vagrant/neovim/build/../src/nvim/event/loop.c:63:3 5 0x185451c in tui_main /home/vagrant/neovim/build/../src/nvim/tui/tui.c:362:12 6 0x18a3080 in ui_thread_run /home/vagrant/neovim/build/../src/nvim/ui_bridge.c:106:3 7 0x7fc3caaac6b9 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x76b9) 8 0x7fc3c9ca33dc in clone /build/glibc-bfm8X4/glibc-2.23/misc/../sysdeps/unix/sysv/linux/x86_64/clone.S:109 0x6040000024c0 is located 0 bytes to the right of 48-byte region [0x604000002490,0x6040000024c0) allocated by thread T1 here: 0 0x50e048 in malloc (/home/vagrant/neovim/build/bin/nvim+0x50e048) 1 0xf7ab71 in try_malloc /home/vagrant/neovim/build/../src/nvim/memory.c:87:15 2 0xf7ad99 in xmalloc /home/vagrant/neovim/build/../src/nvim/memory.c:121:15 3 0x187937b in ugrid_resize /home/vagrant/neovim/build/../src/nvim/ugrid.c:32:17 4 0x184be58 in tui_resize /home/vagrant/neovim/build/../src/nvim/tui/tui.c:770:3 5 0x18a3dc8 in ui_bridge_resize_event /home/vagrant/neovim/build/src/nvim/auto/ui_events_bridge.generated.h:4:3 6 0xa4dcda in multiqueue_process_events /home/vagrant/neovim/build/../src/nvim/event/multiqueue.c:150:7 7 0xa478bf in loop_poll_events /home/vagrant/neovim/build/../src/nvim/event/loop.c:63:3 8 0x185451c in tui_main /home/vagrant/neovim/build/../src/nvim/tui/tui.c:362:12 9 0x18a3080 in ui_thread_run /home/vagrant/neovim/build/../src/nvim/ui_bridge.c:106:3 10 0x7fc3caaac6b9 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x76b9) Thread T1 created by T0 here: 0 0x4655ed in __interceptor_pthread_create (/home/vagrant/neovim/build/bin/nvim+0x4655ed) 1 0x1ad87b0 in uv_thread_create /home/vagrant/neovim/.deps/build/src/libuv/src/unix/thread.c:75 2 0x184b9aa in tui_start /home/vagrant/neovim/build/../src/nvim/tui/tui.c:159:10 3 0x188dd4c in ui_builtin_start /home/vagrant/neovim/build/../src/nvim/ui.c:125:3 4 0xe6d399 in main /home/vagrant/neovim/build/../src/nvim/main.c:457:5 5 0x7fc3c9bbc82f in __libc_start_main /build/glibc-bfm8X4/glibc-2.23/csu/../csu/libc-start.c:291
* tui: support TERM=konsole-256colorJustin M. Keyes2018-01-01
| | | | | | | | | | | | | TERM=konsole-256color is recognized by ncurses. TERM=konsole-xterm might be more clever, but should not be necessary (for Nvim at least), we already special-case Konsole in various places. We may need to clean up some areas that currently assume Konsole always "pretends xterm" (`TERM=xterm-256color`), though I didn't find any such cases. ref #6403 ref https://github.com/neovim/neovim/issues/6403#issuecomment-348713346
* Merge branch 'master' into hide-container-implZyX2017-12-23
|\
| * tui: rework deferred-termcodes ... againJustin M. Keyes2017-12-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Revert timer-based approach. - Instead, call loop_poll_events() with a timeout in an "active" loop, to infer that "TUI startup activity has mostly finished", but also to enforce a mininum time (100 ms) before emitting "enable focus reporting" termcode. (If TUI startup takes longer than that minimum time, it's probably a slow environment anyways.) - Tickle `main_loop` by sending a dummy event. Without this, the initial "focus-gained" response from the terminal may not get processed until the user hits a key. ref #7720 ref #7664 ref #7649 ref #7664 ref 27f9b1c7b029d8
* | Merge branch 'master' into hide-container-implZyX2017-12-16
|\|
| * tui: defer termcodes using a timerJustin M. Keyes2017-12-13
| | | | | | | | | | | | | | | | | | | | | | | | | | With this implementation there is no "jank" during startup. Using the main_loop in any fashion is janky. Using only the TUI loop emits the termcodes too soon, or requires bad hacks like counting tui_flush invocations (9 seems to work). ref #7664 ref #7649 ref #7664 ref 27f9b1c7b029d8
| * tui: rework deferred-termcodes implementationJustin M. Keyes2017-12-13
| | | | | | | | | | | | | | | | | | | | Try another approach to defer the termcodes. Seems less janky, but still not perfect. ref #7664 ref #7649 ref #7664 ref 27f9b1c7b029d8
| * ui: forward relevant option updates to UIs (#7520)Björn Linse2017-12-12
| | | | | | also make termguicolors mutable after startup
* | *: Fix linter errorsZyX2017-12-12
|/
* docJustin M. Keyes2017-12-10
| | | | closes #7622
* Merge #7676 from florolf/atomic-unibiliumJustin M. Keyes2017-12-06
|\ | | | | closes #7381
| * tui: always hide cursor when flushingFlorian Larysch2017-12-05
| | | | | | | | | | | | | | The previous commit ensures that we can never flush the buffer in a state where toggling cursor visibility can corrupt other escape codes. Thus, we can remove the workaround added as part of e838452, simplyfing the code and hiding the cursor on more occasions.
| * tui: never flush buffers in midst of unibilium outputFlorian Larysch2017-12-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | e83845285 fixed an issue where long (true color) escape sequences got interrupted by the cursor visibility toggling caused by buffer flushes. cdfaecb25 introduces a new issue which causes similar problems: While the old buffer flushing code appended the cursor visibility escapes to the buffer before/after flushing, the new code effectively prepends the sequences. Assume the following sequence of events occurs: - A long escape code is issued using unibi_out when the buffer is almost full - out() gets called for a prefix of that escape code, causing the buffer to fill up - flush_buf(ui, false) is called and (correctly) does not insert any cursor toggling escapes - The rest of the escape code is written into the now empty buffer - At some later point, some other part of nvim calls flush_buf(ui, true), which then toggles the cursor, corrupting the escape code This could possibly also be fixed by tracking the state of the buffer (i.e. does it contain a partially output escape code?), but this seems fragile in the same way e83845285 turned out to be. The root cause for all these problems is the mismatch between nvim's (implicit) assumption that the buffer is flushable at any point in time and the non-atomicity of unibilium's character based callback interface. The proper fix (without modifying unibilium) is to ensure nvim's assumption about the buffer state holds at all times. To that end, add a "cork" flag which ensures one unibi_out-call never splits its output across a buffer flush; if an escape code does not fit into the current buffer, flush it without any part of the escape code in it and insert the whole escape code in the emptied buffer. This is a little more complex because it modifies the buffer in place rather than printing into another buffer, checking the remaining space in the terminal buffer and then memcpy'ing it.
* | tui: ignore st terminfo cursor shape (Se, Ss) entriesJustin M. Keyes2017-12-06
| | | | | | | | closes #7641
* | tui: flush -V3 ('verbose' >= 3) info ASAPJustin M. Keyes2017-12-05
| |
* | tui: set descriptions on termcap extensionsJustin M. Keyes2017-12-05
| |
* | tui: dump termcap info if -V3 ('verbose' >= 3)Justin M. Keyes2017-12-05
|/ | | | | | | | | Get terminal debugging info by starting Nvim with 'verbose' level 3: nvim -V3log This is like Vim's `:set termcap`, which was removed in Nvim (and would be very awkward to restore because of the decoupled UI).
* tui.c: request focus-reporting (fix regression) #7670Justin M. Keyes2017-12-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ref #7649 ref #7664 27f9b1c7b029d8 caused a regression: it uses loop_schedule_deferred() to defer emitting the "enable focus reporting" termcode. tui_main() never processes `tui_loop.events` (which loop_schedule_deferred() depends on), so the event was never actually processed. But fixing that (by processing `tui_loop.events`) would bring back the problem 27f9b1c7b029 tried to fix: it still emits the event too soon. Instead, do a little dance: schedule the event on `main_loop` and then forward it to `tui_loop`. NOTE: after this commit, in tmux 2.3 with `focus-events` enabled, FocusGained is fired on startup and when resuming from suspend. Using `script` to record the terminal session (and `vterm-dump` to post-process the result): BEFORE: {DECSM 1049}{DECSM 1}{ESC =} {CUP *}{ED *}{DECSM 2004}{DECSM 1004}{CSI 1,43 r} {CUP 1,1} {CUP *}{ED *}{SM 34}{DECSM 25} {DECRM 25}{CSI 2 q}{CSI 2 q} {CUP *}{ED *}{LF} {SGR *}{LS1}{SGR 94}~ ... AFTER: {CUP *}{ED *}{CSI 1,43 r} {CUP 1,1} {CUP *}{ED *}{SM 34}{DECSM 25} {DECRM 25}{CSI 2 q}{CSI 2 q} {CUP *}{ED *}{DECSM 2004}{DECSM 1004}{LF} {SGR *}{LS1}{SGR 94}~ ...
* tui: emit some termcodes later (after startup) (#7664)Justin M. Keyes2017-12-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For some reason, enabling focus reporting during terminal setup, causes slow rendering during Nvim startup on tmux 2.3 with the tmux `focus-events` option enabled. To workaround that issue, this commit defers the request. closes #7649 init.vim: call plug#begin('~/.config/nvim/plugged') Plug 'morhetz/gruvbox' call plug#end() set background=light " background light just to see the effect more quickly colorscheme gruvbox .tmux.conf: set -g focus-events on set-option -ga terminal-overrides ",xterm-256color:Tc" set-option -g default-terminal "screen-256color" Using `script` to record the terminal session (and `vterm-dump` to post-process the result): BEFORE this commit: ./build/bin/nvim -u NONE{CR}{LF} {DECSM 1049}{DECSM 1}{ESC =} {CUP *}{ED 2}{DECSM 2004}{DECSM 1004}{CSI 8,44,156 t}{CSI * r} {CUP 1,1} {CUP *}{ED 2}{DECSM 25} {DECRM 25}{CSI 2 q}{CSI 2 q} {CUP *}{ED 2}{LF} {ESC (B}{SGR *}{SGR 94}~ {CR}{LF} ~ {CR}{LF} AFTER this commit: ./build/bin/nvim -u NONE{CR}{LF} {DECSM 1049}{DECSM 1}{ESC =} {CUP *}{ED 2}{CSI 8,44,156 t}{CSI * r} {CUP 1,1} {CUP *}{ED 2}{DECSM 2004}{DECSM 1004}{DECSM 25} {DECRM 25}{CSI 2 q}{CSI 2 q} {CUP *}{ED 2}{LF} {ESC (B}{SGR *}{SGR 94}~ {CR}{LF} ~ {CR}{LF} ...
* tui/rxvt: enable focus-reportingJustin M. Keyes2017-12-01
| | | | closes #7578
* Revert "tui: update cleared area only if non-default bg"Justin M. Keyes2017-11-29
| | | | | | | | Reverts 0b93bab6c22edf7a07cf965ebbbf631b93e1dc1b. This change was counter-productive to the other changes which intended to reduce the role of BCE. ref #7624
* tui: expose terminal type in 'term' optionJustin M. Keyes2017-11-27
| | | | | | | | | | Since "builtin" terminfo definitions were implemented (7cbf52db1bdf), the decisions made by tui.c and terminfo.c are more relevant. Exposing that decision in the 'term' option helps with troubleshooting. Also: remove code that allowed setting t_Co. `:set t_Co=…` has never worked; the highlight_spec test asserting that nvim_set_option('t_Co') _does_ work makes no sense, and should not have worked.
* tui: update cleared area only if non-default bgJustin M. Keyes2017-11-24
| | | | This check was removed in 133ae5eeeff3 without explanation.
* tui: Disable BCE almost always. #7624Justin M. Keyes2017-11-24
| | | | | | | | | | 133ae5eeeff3 implemented BCE (background color erase). But we can't trust terminfo, so it is safer disable BCE if we are not certain. Per https://github.com/kovidgoyal/kitty/issues/160#issuecomment-346470545 terminal support for BCE seems to be (1) optional and (2) inconsistent. ref #4210 #4421 #7035 #7337 #7381 #7425 #7618
* tui: Disable BCE by default. #7624Justin M. Keyes2017-11-23
| | | | | | | | | | | | 133ae5eeeff3 implemented BCE (background color erase). That's fine if the system terminfo claims to support it; but our built-in fallback should not assume it. Per https://github.com/kovidgoyal/kitty/issues/160#issuecomment-346470545 terminal support for BCE seems to be (1) optional and (2) inconsistent. So the built-in terminfos should disable it by default. ref #4210 #4421 #7035 #7337 #7381 #7425 #7618
* tui: move terminfo_is_term_family()Justin M. Keyes2017-11-22
|
* Merge #7593 'PVS static analysis fixes'Justin M. Keyes2017-11-22
|\
| * Fix for pvs V782, pointer access to first element of arrayPeter Kalauskas2017-11-22
| |
| * input.c: replace if/else with switchPeter Kalauskas2017-11-22
|/
* tui: setrgbf/setrgbb: emit semicolons for VTEJustin M. Keyes2017-11-18
| | | | | | | Severe memory leak observed on gnome-terminal 3.26.2 VTE 0.50.2 when colon-delimited RGB sequences are used. closes #7573
* tui: 'guicursor': use DECSCUSR for xterm-likes (#7576)Justin M. Keyes2017-11-17
| | | | | | | Anything claiming to be an xterm gets DECSCUSR. This is the only reasonable choice unless/until we get more reliable detection (#7490). ref #6997 closes #7550
* Adds nvim_get_hl_by_name/by_idMatthieu Coudron2017-09-30
| | | | | | | | | ...in order to retrieve highlights. Added test/functional/api/highlight_spec.lua HL_NORMAL is not really a good name, since it's more like an empty attribute than the normal's one. If one pays attention, syn_cterm_attr2entry is never called with attr=0 because it's always special cased before. I suggest in subsequent PRs we remove the ATTR_OFF and just insert an EMPTY ATTR/RESET_ATTR/UNINITIALIZED for id 0.
* tui: Use unibi_var_from_num when availableJames McCoy2017-09-16
| | | | | | | | | | | | | | | | | | As of unibilium 1.2.1, directly manipulating unibi_var_t is deprecated. ../src/nvim/tui/tui.c: In function 'update_attrs': ../src/nvim/tui/tui.c:321:7: warning: 'i' is deprecated: use unibi_var_from_num or unibi_num_from_var instead [-Wdeprecated-declarations] data->params[0].i = (fg >> 16) & 0xff; // red ^~~~ In file included from ../src/nvim/tui/tui.c:12:0: /usr/include/unibilium.h:632:9: note: declared here int i UNIBI_DEPRECATED("use unibi_var_from_num or unibi_num_from_var instead"); ^ All use should go through unibi_{num,str}_from_var and unibi_var_from_{num,str}. Wrap access of unibi_var_t behind a new UNIBI_SET_NUM_VAR macro which uses the new functions when they're available.
generated by cgit (git 2.34.1) at 2026-07-03 05:43:07 +0000