Makes the 'scrollback' option more consistent (same default for all buffers) and future-proof.
- Default to -1 for all buffers, but treat it as an implementation detail.
- Document range of 1 - 100_000.
- New terminal buffer by default sets scrollback=10_000 if the global default is -1.
- Existing terminal buffer: On entering terminal-mode or on refresh, if the user explicitly did `:set[local] scbk=-1`, the local value goes to 100_000 (max). (This is undocumented on purpose. Users should work with explicit values in the range of 1-100_000.)
- Avoid using platform-specific shell, it failed in MINGW_64 env.
- tty-test.c echos our input, which is exactly what we need for this test.
- Test fails correctly if 894f6bee54 is reverted.
wp->w_height_inner now contains the "inner" size, regardless if the
window has been drawn yet or not. It should be used instead of
wp->w_grid.Rows, for stuff that is not directly related to accessing
the allocated grid memory, such like cursor movement and terminal size
By historical accident, Nvim defaults to background=light. So on a dark
background, `:colorscheme default` looks completely wrong.
The "smart" logic that Vim uses is confusing for anyone who uses Vim on
multiple platforms, so rather than mimic that, pick the (hopefully) most
common default.
- Since Neovim is dark-powered, we assume most users have dark backgrounds.
- Most of the GUIs tend to have a dark background by default.
ref #6289
- window_split_tab_spec.lua: Put cursor at bottom of :terminal buffer so
that it follows output.
- inccommand_spec.lua: Increase timeout to allow 2nd retry.
- Timer tests are less reliable on Travis CI macOS 10.12/10.13.
ref #6829
ref e39dade80b
ref de13113dc1
ref https://github.com/neovim/neovim/pull/9095#issuecomment-429603452
> We don't guarantee that a X ms timer is triggered during Y ms sleep
> for any X<Y, though I would expect the load to be really bad for this
> to happen with X=10ms, Y=40ms.
Add ext_newgrid and ext_hlstate extensions. These use predefined
highlights and line-segment based updates, for efficiency and
simplicity.. The ext_hlstate extension in addition allows semantic
identification of builtin and syntax highlights.
Reimplement the old char-based updates in the remote UI layer, for
compatibility. For the moment, this is still the default. The bulitin
TUI uses the new line-based protocol.
cmdline uses curwin cursor position when ext_cmdline is active.
Show a proper confirmation dialog when trying to unload a terminal buffer while
the confirm option is set or when :confirm is used.
Fixes https://github.com/neovim/neovim/issues/4651
closes#7698
Wrapping a command in double-quotes allows cmd.exe to safely dequote the
entire command as if the user entered the entire command in an
interactive prompt. This reduces the need to escape nested and uneven
double quotes.
The `/s` flag of cmd.exe makes the behaviour more reliable:
:set shellcmdflag=/s\ /c
Before this patch, cmd.exe cannot use cygwin echo.exe (as opposed to
cmd.exe `echo` builtin) even if it is wrapped in double quotes.
Example:
:: internal echo
> cmd /s /c " echo foo\:bar" "
foo\:bar"
:: cygwin echo.exe
> cmd /s /c " "echo" foo\:bar" "
foo:bar
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.
The old behavior is probably not justified, for the usual reason:
terminal buffers may have interactive processes, so cursor placement is
arbitrary, therefore tracking it in the jumplist is useless (or worse).
N.B.: per the docstring for `checkpcmark()` it looks like we were
calling `checkpcmark()` and `setpcmark()` in the wrong order.
closes#3723
closes#7572closes#7579closes#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
Since "builtin" terminfo definitions were implemented (7cbf52db1b),
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.
This fixes an apparent difference in behavior between Lua and LuaJIT.
Lua fails to format nil:
test/functional/terminal/tui_spec.lua:381: bad argument #2 to 'format' (string expected, got nil)
To deal with SIGWINCH limitations on Windows, change some resize tests
to _shrink_ the screen width. ... But this didn't work, so still
ignoring those tests on Windows.
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.
Calling cmd.exe in Windows follows a very different pattern from Vim.
The primary difference is that Vim does a nested call to cmd.exe, e.g.
the following call in Vim
system('echo a 2>&1')
spawns the following processes
"C:\Program Files (x86)\Vim\vim80\vimrun" -s C:\Windows\system32\cmd.exe /c (echo a 2^>^&1
^>C:\Users\dummy\AppData\Local\Temp\VIoC169.tmp 2^>^&1)
C:\Windows\system32\cmd.exe /c C:\Windows\system32\cmd.exe /c (echo a 2^>^&1
^>C:\Users\dummy\AppData\Local\Temp\VIo3C6C.tmp 2^>^&1)
C:\Windows\system32\cmd.exe /c (echo a 2>&1
>C:\Users\dummy\AppData\Local\Temp\VIo3C6C.tmp 2>&1)
The escaping with ^ is needed because cmd.exe calls itself and needs to
preserve the special metacharacters for the last call. However in nvim
no nested call is made, system('') spawns a single cmd.exe process.
Setting shellxescape to "" disables escaping with ^.
The previous default for shellxquote=( wrapped any command in
parenthesis, in Vim this is more meaningful due to the use of tempfiles
to store the output and redirection (also see &shellquote). There is
a slight benefit in having the default be empty because some expressions
that run in console will not run within parens e.g. due to unbalanced
double quotes
system('echo "a b')
It looks like Neovim has a bug: if `startinsert` is called using `command()`
then `-- TERMINAL --` gets replaced with `-- --` (and also a cursor appears).
Hope this will make people using feed_command less likely: this hides bugs.
Already found at least two:
1. msgpackparse() will show internal error: hash_add() in case of duplicate
keys, though it will still work correctly. Currently silenced.
2. ttimeoutlen was spelled incorrectly, resulting in option not being set when
expected. Test was still functioning somehow though. Currently fixed.
Removed the call to validate_cursor() because mb_check_adjust_col() is
already called in adjust_topline().
Closes#6378
References #6203https://s3.amazonaws.com/archive.travis-ci.org/jobs/215498258/log.txt
[ ERROR ] ...ovim/neovim/test/functional/terminal/scrollback_spec.lua @ 386: 'scrollback' option set to 0 behaves as 1 (10621.17 ms)
==================== File /home/travis/build/neovim/neovim/build/log/ubsan.12836 ====================
= =================================================================
= ==12836==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62100002cd00 at pc 0x000000eafe90 bp 0x7ffc8661fe50 sp 0x7ffc8661fe48
= READ of size 1 at 0x62100002cd00 thread T0
= #0 0xeafe8f in utf_head_off /home/travis/build/neovim/neovim/src/nvim/mbyte.c:1457:7
= #1 0x6b890e in getvcol /home/travis/build/neovim/neovim/src/nvim/charset.c:1169:15
= #2 0x6bc777 in getvvcol /home/travis/build/neovim/neovim/src/nvim/charset.c:1336:5
= #3 0xfc067b in curs_columns /home/travis/build/neovim/neovim/src/nvim/move.c:730:5
= #4 0xfbc8db in validate_cursor /home/travis/build/neovim/neovim/src/nvim/move.c:510:5
= #5 0x14479ed in setcursor /home/travis/build/neovim/neovim/src/nvim/screen.c:6363:5
= #6 0x17fe054 in redraw /home/travis/build/neovim/neovim/src/nvim/terminal.c:1175:5
= #7 0x17f95e4 in terminal_enter /home/travis/build/neovim/neovim/src/nvim/terminal.c:392:3
= #8 0x70eb2b in edit /home/travis/build/neovim/neovim/src/nvim/edit.c:1300:7
= #9 0x11097d1 in normal_finish_command /home/travis/build/neovim/neovim/src/nvim/normal.c:947:13
= #10 0x1081191 in normal_execute /home/travis/build/neovim/neovim/src/nvim/normal.c:1138:3
= #11 0x170b813 in state_enter /home/travis/build/neovim/neovim/src/nvim/state.c:58:26
= #12 0x103631b in normal_enter /home/travis/build/neovim/neovim/src/nvim/normal.c:464:3
= #13 0xdfb7a8 in main /home/travis/build/neovim/neovim/src/nvim/main.c:552:3
= #14 0x2b8a3c85bf44 in __libc_start_main /build/eglibc-MjiXCM/eglibc-2.19/csu/libc-start.c:287
= #15 0x447b25 in _start (/home/travis/build/neovim/neovim/build/bin/nvim+0x447b25)
=
= 0x62100002cd00 is located 0 bytes to the right of 4096-byte region [0x62100002bd00,0x62100002cd00)
= allocated by thread T0 here:
= #0 0x4f1e98 in malloc (/home/travis/build/neovim/neovim/build/bin/nvim+0x4f1e98)
= #1 0xf28774 in try_malloc /home/travis/build/neovim/neovim/src/nvim/memory.c:84:15
= #2 0xf28934 in xmalloc /home/travis/build/neovim/neovim/src/nvim/memory.c:118:15
= #3 0xec7be8 in mf_alloc_bhdr /home/travis/build/neovim/neovim/src/nvim/memfile.c:646:17
= #4 0xec58d4 in mf_new /home/travis/build/neovim/neovim/src/nvim/memfile.c:297:12
= #5 0xeda8a8 in ml_new_data /home/travis/build/neovim/neovim/src/nvim/memline.c:2697:16
= #6 0xed7beb in ml_open /home/travis/build/neovim/neovim/src/nvim/memline.c:349:8
= #7 0x643fcd in open_buffer /home/travis/build/neovim/neovim/src/nvim/buffer.c:109:7
= #8 0xa7038c in do_ecmd /home/travis/build/neovim/neovim/src/nvim/ex_cmds.c:2483:24
= #9 0xb5bb49 in do_exedit /home/travis/build/neovim/neovim/src/nvim/ex_docmd.c:6839:9
= #10 0xb7b6d8 in ex_edit /home/travis/build/neovim/neovim/src/nvim/ex_docmd.c:6767:3
= #11 0xb2a598 in do_one_cmd /home/travis/build/neovim/neovim/src/nvim/ex_docmd.c:2208:5
= #12 0xb08f47 in do_cmdline /home/travis/build/neovim/neovim/src/nvim/ex_docmd.c:602:20
= #13 0x109997b in nv_colon /home/travis/build/neovim/neovim/src/nvim/normal.c:4492:18
= #14 0x1081188 in normal_execute /home/travis/build/neovim/neovim/src/nvim/normal.c:1135:3
= #15 0x170b813 in state_enter /home/travis/build/neovim/neovim/src/nvim/state.c:58:26
= #16 0x103631b in normal_enter /home/travis/build/neovim/neovim/src/nvim/normal.c:464:3
= #17 0xdfb7a8 in main /home/travis/build/neovim/neovim/src/nvim/main.c:552:3
= #18 0x2b8a3c85bf44 in __libc_start_main /build/eglibc-MjiXCM/eglibc-2.19/csu/libc-start.c:287
=
= SUMMARY: AddressSanitizer: heap-buffer-overflow /home/travis/build/neovim/neovim/src/nvim/mbyte.c:1457:7 in utf_head_off
= Shadow bytes around the buggy address:
= 0x0c427fffd950: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
= 0x0c427fffd960: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
= 0x0c427fffd970: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
= 0x0c427fffd980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
= 0x0c427fffd990: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
= =>0x0c427fffd9a0:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
= 0x0c427fffd9b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
= 0x0c427fffd9c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
= 0x0c427fffd9d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
= 0x0c427fffd9e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
= 0x0c427fffd9f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
= Shadow byte legend (one shadow byte represents 8 application bytes):
= Addressable: 00
= Partially addressable: 01 02 03 04 05 06 07
= Heap left redzone: fa
= Heap right redzone: fb
= Freed heap region: fd
= Stack left redzone: f1
= Stack mid redzone: f2
= Stack right redzone: f3
= Stack partial redzone: f4
= Stack after return: f5
= Stack use after scope: f8
= Global redzone: f9
= Global init order: f6
= Poisoned by user: f7
= Container overflow: fc
= Array cookie: ac
= Intra object redzone: bb
= ASan internal: fe
= Left alloca redzone: ca
= Right alloca redzone: cb
= ==12836==ABORTING
=====================================================================================================
./test/helpers.lua:82: assertion failed!
stack traceback:
./test/helpers.lua:82: in function 'check_logs'
./test/functional/helpers.lua:643: in function <./test/functional/helpers.lua:642>
Make the 'scrollback' option work like most other buffer-local options:
- `:set scrollback=x` sets the global and local value
- `:setglobal scrollback=x` sets only the global default
- new terminal buffers inherit the global
Normal buffers are still always -1, and :setlocal there is an error.
Closes#6337
Tokenize p_sh if used as default in ex_terminal(). Previously p_sh was
used as the first arg in a list when calling termopen(), this would try
to call an untokenized version of shell, meaning if you had an argument
in 'shell':
set shell=/bin/bash\ --login
the command would fail.
Helped-by: oni-link <knil.ino@gmail.com>
Closes#3999
- Vim "unix default" of 'noshowcmd' is serving few users. And it's
inconsistent.
- 'ruler' and 'belloff=all' improve the out-of-the-box experience.
- Continue to use 'noshowcmd' and 'noruler' by default in the functional
tests to keep them fast.
TODO: Add a "disable slow stuff" command or mapping to address the
use-case of a very slow terminal connection.
After using 'termopen("echo") the current buffer content is changed,
but the cursor position of the current window is not updated.
Because of this, a call to 'mb_adjust_cursor()' can lead to a
heap-buffer-overflow.
Fix this by resetting the cursor for the current window.
Fixes#3161
Let the terminal dictate the normal-mode cursor position. This will be
disorienting sometimes, but it is closer to what users expect vs always
going to the last line.
Periodically skip :! spam. This is a "cheat" that works for all UIs and greatly
improves responsiveness when :! spams MB or GB of output:
:!yes
:!while true; do date; done
:!git grep ''
:grep -r '' *
After ~10KB of data is seen from a single :! invocation, output will be skipped
for ~1s and three dots "..." will pulse in the bottom-left. Thereafter the
behavior alternates at every:
* 10KB received
* ~1s throttled
This also avoids out-of-memory which could happen with large :! outputs.
Note: This commit does not change the behavior of execute(':!foo').
execute(':!foo') returns the string ':!foo^M', it captures *only* Vim
messages, *not* shell command output. Vim behaves the same way.
Use system('foo') for capturing shell command output.
Closes#1234
Helped-by: oni-link <knil.ino@gmail.com>
https://github.com/mpeterv/luacheck/pull/81#issuecomment-261099606
> If you really want to use bleeding-edge version you should get the
> rockspec from master branch, not a fixed commit ...
> The correct way to install from a specific commit is cloning that
> commit and running "luarocks make" from project directory. The reason
> is that running "install" or "build" on an scm rockspec fetches
> sources from master but uses build description from the rockspec
> itself, which may be outdated.
add tests for synIDattr() with [fg|bg|sp]#
add tests for synIDattr and various #RGB colors
synIDattr: test for ui_rgb_attached()
test: fix tests for synIDattr fg/bg/sp
It is otherwise impossible to determine which test failed sanitizer/valgrind
check. test/functional/helpers.lua module return was changed so that tests which
do not provide after_each function to get new check will automatically fail.
This was not a problem locally, but would often/sometimes/etc. (YMMV) fail on QB
and/or travis. This seems to fix it. Quoting @justinmk: "I have a feeling this
is just a bug in the bracketed paste special-cases in the existing code".
The hexadecimal notation is a Luajit extension which is not compatible with Lua
5.1. While Lua 5.2 does support hexadecimal sequences, it is better to target
Lua 5.1 for maximum compatibility with Luajit(which has fully compatible with
5.1 API/ABI).
Background: Vim internally prefers to represent ALT/META chords as
single-byte keys, by setting the high bit of the key byte.
extract_modifiers() _discards_ the meta/alt modifier, but we need it for
libvterm and libtermkey.
Closes#2440Closes#3727Closes#2017
References #2277
References #2254https://github.com/neovim/neovim/issues/2017#issuecomment-140423557
> We [not libtermkey] are setting the high bit for some reason
https://github.com/neovim/neovim/issues/176#issuecomment-77834715
> libvtermkey requires the leading esc to parse alt/meta
https://github.com/neovim/neovim/pull/3246#issuecomment-136328450
> A program could do better than the current logic on some terminals, by
> asking for pure 8bit mode (S8C1T) and then immediately querying the
> mode again. If the result comes back as an 8bit single-byte CSI, then
> it can presume the mode setting was successful, and now the ESC prefix
> byte won't be seen in multibyte sequences; only as an Alt- prefix or
> a real Escape key. On such a terminal, it could therefore avoid
> needing to use that waiting timeout.
This change adds switch cases for K_FOCUSGAINED and K_FOCUSLOST to the
input handling functions in ex_getln.c and terminal.c. The handling is
identical to what's found in edit.c (just calling apply_autocmds).
If one enters cmdline-mode by feeding `:` and sends a focuslost event (by
leaving the window for example) the text `<FocusLost>` will be inserted
into the command line. There is similar behaviour in terminal mode. This
patch corrects this behavior to fire the apropriate autocmd instead.
Fixes#3714
Previously, the screen test was expecting the screen state to be
identical to the previous screen test in `thelpers.screen_setup()`,
which is indeterministic. (The later screen test can accidentally
still see the previous identical state). The solution is to add a test
for a intermediate different state.
Old behaviour: termopen('cmd') would run `&shell &shcf "cmd"`, which
caused the functional tests to fail on some systems due to the process
not "owning" the terminal. Also, it is inconsistent with jobstart().
Modify termopen() so that &shell is not invoked, but maintain the old
behaviour with :terminal. Factor the common code for building the
argument vector from jobstart() and modify the functional tests to call
termopen() instead of :terminal (fixes#2354).
Also:
* Add a 'name' option for termopen() so that `:terminal {cmd}` produces
a buffer named "term//{cwd}/{cmd}" and termopen() users can customize
the name.
* Update the documentation.
* Add functional tests for `:terminal` sinse its behaviour now differs
from termopen(). Add "test/functional/fixtures/shell-test.c" and move
"test/functional/job/tty-test.c" there, too.
Helped-by: Justin M. Keyes <@justinmk>
Pressing <C-\> and then a mouse click will insert the click into the
terminal as if a keyboard button had been pressed.
Keep track of whether the last input was <C-\> and only call
terminal_send_key() if the next input is a key press.
While in a terminal and insert mode, if an event caused loss of focus,
nvim would stay in the terminal event loop causing an inconsistent view
of internal state and/or segfault.
Remove the "term" argument from terminal_enter() as it only makes sense
to call it with curbuf->terminal. Terminate the loop when switched to a
different buffer.
fixes#2301
- Modify tty-test to allow easier control over the terminal
- Add a new directory with various terminal tests/specifications
- Remove a pending job/pty test.
- Flush stdout in Screen:snapshot_util() (avoid waiting for the test to finish)
- Replace libuv sigwinch watcher by a sigaction handler. libuv randomly fails to
deliver signals on OSX. Might be related to the problem fixed by
@bbcddc55ee1e5605657592644be0102ed3a5f104 (under the hoods, libuv uses a pipe
to deliver signals to the main thread, which might be blocking in some
situations)
