Problem: Command overlaps with printed text in scrollback.
Solution: Clear until end-of-line and use correct message chunk.
(closesvim/vim#10765, closesvim/vim#10764)
ecdc82e74e
N/A patches for version.c:
vim-patch:9.0.0070: using utfc_ptr2char_len() when length is negative
Problem: Using utfc_ptr2char_len() when length is negative.
Solution: Check value of length. (closesvim/vim#10760)
4dc513a22c
* fix(test): screen.lua nil index
When actual_rows and expected_rows are different avoid a nil index.
* fix(tui): resize at startup
The deleted code is not needed after 402b4e8.
It caused the condition to false positive when the function was called
more than once before startup (first normal mode). Being itself what
set the dimension and not the user, locking the size of the screen to
an incorrect size.
Make got_winch an int to mitigate: tui_grid_resize changing the size
of the host terminal between the signal handler and the call to
sigwinch_cb. Since the actual signal handler uv__signal_handle doesn't
directly call the callback, the event loop does.
Fixes#17285Fixes#15044Fixes#11330
Problem:
- Since c57f6b28d7#8519, sockets are created in ~/.local/… but XDG
spec says: "XDG_RUNTIME_DIR: Must be on the local filesystem", which
implies that XDG_STATE_DIR is potentially non-local.
- Not easy to inspect Nvim-created temp files (for debugging etc).
Solution:
- Store sockets in stdpath('run') ($XDG_RUNTIME_DIR).
- Establish "/tmp/nvim.user/" as the tempdir root shared by all Nvims.
- Make ok() actually useful.
- Introduce assert_nolog().
closes#3517closes#17093
Ref: 84f5463630
Rename:
- `underlineline` to `underdouble`
- `underdot` to `underdotted`
- `underdash` to `underdashed`
`underdouble` also now takes higher precedence than `undercurl`.
Problem:
- Unix sockets are created in random /tmp dirs.
- /tmp is messy, unclear when OSes actually clear it.
- The generated paths are very ugly. This adds friction to reasoning
about which paths belong to which Nvim instances.
- No way to provide a human-friendly way to identify Nvim instances in
logs or server addresses.
Solution:
- Store unix sockets in stdpath('state')
- Allow --listen "name" and serverstart("name") to given a name (which
is appended to a generated path).
TODO:
- is stdpath(state) the right place?
* on_scrollback_option_changed renamed to adjust_scrollback. The
function name did not correspond to what it was doing. It is
called unconditionally in every refresh of the terminal
unrelated if the scrollback option was changed.
* new on_scrollback_option_changed function, which calls
refresh_terminal, which then calls adjust_scrollback
* terminal_check_size is not the appropriate function to call when the
option is changed since it only conditionally adjusts the scrollback.
Use the new on_scrollback_option_changed
fixes#15477fixes#11811
Remove the command('qall!') from mksession_spec.lua because it prevents
helpers.rmdir() from retrying.
Allow extra trailing spaces when matching terminal lines.
This make Nvim recognize `ESC NUL` as <M-C-Space>, as many terminal
emulators (including libvterm) send <M-C-Space> as `ESC NUL`.
There is already another unambiguous way to encode a `ESC` key supported
by libtermkey: `ESC [ 2 7 u`, which is a `CSI u` sequence.
If one still wants to use `ESC NUL` as `ESC`, they can just map
<M-C-Space> to <Esc>.
- Fix the problem that chanclose() does not work for channel created by
nvim_open_term().
- Fix the problem that the loopback channel is not released.
- Fix the error message when sending raw data to the loopback channel.
This commit fixes regression introduced in c365de1 when checking for
highlight attribute for underline was returning '0' when it was present
Fixes#17624.
The Lua modules that make up vim.lua are embedded as raw source files into the
nvim binary. These sources are loaded by the Lua runtime on startuptime. We can
pre-compile these sources into Lua bytecode before embedding them into the
binary, which minimizes the size of the binary and improves startuptime.
refresh_scrollback assumes pending scrollback rows exist only if the
terminal window height decreased (or the screen was full).
However, after accumulating scrollback, it's possible in some cases for
the terminal height to increase before refresh_scrollback is called via
invalidation (especially when the terminal buffer isn't initially
displayed in a window before nvim_open_term), which may crash.
As we'll have enough room for some scrollback rows, just append them to
the top of the buffer until it fills the window, then continue with the
previous logic for any remaining scrollback rows if necessary.
Problem: Cannot distinguish Normal and Terminal-Normal mode.
Solution: Make mode() return "nt" for Terminal-Normal mode. (issue vim/vim#8856)
72406a4bd2
When entering terminal mode, cursorlineopt is no longer entirely
disabled. Instead, it's set to `number`. Doing so ensures that users
using `set cursorline` combined with `set cursorlineopt=number` have
consistent highlighting of the line numbers, instead of this being
disabled when entering terminal mode.
Co-authored-by: Gregory Anders <greg@gpanders.com>
Co-authored-by: Sean Dewar <seandewar@users.noreply.github.com>
Problem:
jobwait() returns early if the job was stopped, but the job might have
pending callbacks on its event queue which are required to complete its
teardown. State such as term->closed might not be updated yet (by the
pending callbacks), so codepaths such as :bdelete think the job is still
running.
Solution:
Always flush the job's event queue before returning from jobwait().
ref #15349
Problem: Using :wqa exits even if a job runs in a terminal window. (Jason
Felice)
Solution: Check if a terminal has a running job. (closesvim/vim#2654)
7a76092a51
Besides the special-case in get_scrolloff_value(), it makes sense for
'scrolloff' and 'sidescrolloff' to reflect the correct values (for
plugins, scripts, …).
ref 53d607af9c53accfd634435908fb79061f1212b9
ref #11915
ref #12230
Offsets of window were not taken into account when sending mouse
coordinates to the terminal. Therefore, when nu or rnu is set, the mouse
coordinates sent to the terminal were not correct. Change it to send the
correct coordinates by subtract window offset from col.
This makes it possible to restore the working directory of :terminal
buffers when reading those buffers from a session file.
Fixes#11288
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
After PR #8226 an unmapped META key in insert mode behaves like
ESC-<key> (:help i_META).
The behaviour does not fully match, since if <Esc>-<key> is pressed
manually then since it were pressed manually `gotchars` would be called
on the second <key> after insert-mode had already been left.
This would mean that `may_sync_undo` (called from `gotchars`) would
call `u_sync(FALSE)` on the second key (since we would be in normal
mode).
This overall means that <Meta-[something]> behaves differently with
respect to undo than <Esc>[something] when the [something] makes a
change.
As an example, under `nvim -u NONE`:
ihello<M-.>u
leaves the buffer empty, while
ihello<Esc>.u
leaves the buffer with one instance of `hello`.
- Fix by calling u_sync() manually in the new clause under
`normalchar:` in `insert_handle_key`.
- Update test in tui_spec.lua that accidentally relied on the old behaviour.
Flaky failure (Travis CI, macOS):
[ RUN ] :terminal (with fake shell) works with gf: 10518.41 ms FAIL
test/functional/terminal/ex_terminal_spec.lua:248: Row 1 did not match.
Expected:
|*^ready $ echo "scripts/shadacat.py" |
|* |
|*[Process exited 0] |
|:terminal echo "scripts/shadacat.py" |
Actual:
|*^ |
|*[Process exited 0] |
|* |
|:terminal echo "scripts/shadacat.py" |
To print the expect() call that would assert the current screen state, use
screen:snapshot_util(). In case of non-deterministic failures, use
screen:redraw_debug() to show all intermediate screen states.
stack traceback:
test/functional/ui/screen.lua:579: in function '_wait'
test/functional/ui/screen.lua:361: in function 'expect'
test/functional/terminal/ex_terminal_spec.lua:248: in function <test/functional/terminal/ex_terminal_spec.lua:245>
- We already find ourselves renaming nvim_execute_lua in tests and
scripts, which suggests "exec" is the verb we actually want.
- Add "exec" verb to `:help dev-api`.
fixes#11438
Backtrace:
0 schar_from_ascii ( p=0x801cc9e112c3 <error: Cannot access memory at address 0x801cc9e112c3>, c=32 ' ') at ../src/nvim/screen.c:5263
1 0x00007f31460eccc5 in win_line (wp=wp@entry=0x7fffc9df6230, lnum=lnum@entry=11, startrow=startrow@entry=10, endrow=41, nochange=false, number_only=number_only@entry=false) at ../src/nvim/screen.c:4025
2 0x00007f31460eed8e in win_update (wp=wp@entry=0x7fffc9df6230) at ../src/nvim/screen.c:1403
3 0x00007f31460f011f in update_screen (type=<optimized out>) at ../src/nvim/screen.c:502
4 0x00007f3146138ef4 in normal_redraw (s=s@entry=0x7fffd0a5f700) at ../src/nvim/normal.c:1247
5 0x00007f314613b159 in normal_check (state=0x7fffd0a5f700) at ../src/nvim/normal.c:1324
6 0x00007f31460accfe in state_enter (s=0x7fffd0a5f700) at ../src/nvim/state.c:28
7 0x00007f3146143099 in normal_enter (cmdwin=<optimized out>, noexmode=<optimized out>) at ../src/nvim/normal.c:463
8 0x00007f314618b541 in main (argc=<optimized out>, argv=<optimized out>) at ../src/nvim/main.c:580
It is perfectly fine and expected to detach from the screen just by
the UI disconnecting from nvim or exiting nvim. Just keep detach() in
screen_basic_spec, to get some coverage of the detach method itself.
This avoids hang on failure in many situations (though one could argue
that detach() should be "fast", or at least "as fast as resize",
which works in press-return already).
Never use detach() just to change the size of the screen, try_resize()
method exists for that specifically.
PR #8221 took a short-cut when implementing the tests: screen.lua would
translate the linegrid highlight ids back into the old per-cell
attribute description.
Apart from cleaning up technical debt, this enables to check both rgb
and cterm colors in the same expect(), which previously was needlessly
restricted to ext_hlstate tests only.
Meant to fix:
[ ERROR ] test/functional/terminal/tui_spec.lua @ 925: TUI FocusGained/FocusLost in terminal-mode
test/functional/ui/screen.lua:587: Row 6 did not match.
Expected:
|{1:r}eady $ |
|[Process exited 0] |
| |
| |
| |
|*gained |
|{3:-- TERMINAL --} |
Actual:
|{1:r}eady $ |
|[Process exited 0] |
| |
| |
| |
|*:terminal |
|{3:-- TERMINAL --} |
To print the expect() call that would assert the current screen state, use
screen:snapshot_util(). In case of non-deterministic failures, use
screen:redraw_debug() to show all intermediate screen states.
stack traceback:
test/functional/ui/screen.lua:587: in function '_wait'
test/functional/ui/screen.lua:370: in function 'expect'
test/functional/terminal/tui_spec.lua:934: in function <test/functional/terminal/tui_spec.lua:925>
I've thought about adding this, but it might not be really relevant, and
slows down the tests a bit (and a warning "warning: Screen test
succeeded immediately" with another test):
```diff
diff --git i/test/functional/terminal/tui_spec.lua w/test/functional/terminal/tui_spec.lua
index ada073c4e..4bc2ab4e0 100644
--- i/test/functional/terminal/tui_spec.lua
+++ w/test/functional/terminal/tui_spec.lua
@@ -818,6 +818,11 @@ describe('TUI FocusGained/FocusLost', function()
..'", "-u", "NONE", "-i", "NONE", "--cmd", "set noswapfile noshowcmd noruler"]')
feed_data(":autocmd FocusGained * echo 'gained'\n")
feed_data(":autocmd FocusLost * echo 'lost'\n")
+ -- Wait for autocommand to be registered.
+ retry(nil, nil, function()
+ feed_data(":autocmd FocusLost\n")
+ screen:expect{any=" echo 'lost'"}
+ end)
feed_data("\034\016") -- CTRL-\ CTRL-N
end)
```
* handle_background_color: short-circuit if handled already
* Unit tests for handle_background_color
* set waiting_for_bg_response to false in tui_terminal_after_startup
By then it should have been received.
Doing the screen test first might give insights about a possible
(flaky?) failure, where it looks like "feed_data" is processed out of
order:
[ ERROR ] test/functional/terminal/tui_spec.lua @ 561: TUI paste: exactly 64 bytes #10311
test/functional/helpers.lua:388:
retry() attempts: 490
test/functional/terminal/tui_spec.lua:66: Expected objects to be the same.
Passed in:
(table: 0x44042de8) {
*[1] = ' endzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz' }
Expected:
(table: 0x41d6e568) {
*[1] = 'zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz end' }
stack traceback:
test/functional/helpers.lua:388: in function 'retry'
test/functional/terminal/tui_spec.lua:63: in function 'expect_child_buf_lines'
test/functional/terminal/tui_spec.lua:569: in function <test/functional/terminal/tui_spec.lua:561>
Ref: https://github.com/neovim/neovim/pull/11083#issuecomment-534375201
Build log: https://travis-ci.org/neovim/neovim/jobs/588749739#L5597
Before this, --embed UIs (without --headless) would not trigger UIEnter.
For TUI, maybe UIEnter isn't useful, but:
- It is less "surprising"/special.
- Makes documentation simpler.
- When TUI becomes a coprocess, it will happen anyway.
simplify handling of default colors
nvim is always true color internally, remove ui_rgb_attached() check.
Fix "runtime termguicolors" test. The test actually reflected broken behavior
in (parent) nvim: nvim_ui_set_option("rgb", true) was not respected by existing
:terminal instances, so all 16-palette colors became dark blue.
Forcing insert-mode after the first paste-chunk seems to work, as an
alternative to a9e2bae0eb (insert-before-cursor).
NB: Dot-repeat needs to match the original action. Since a9e2bae0eb
changed paste to insert-before-cursor, dot-repeat must also. But that
makes dot-repeat unpleasant/unusual.
Inserting "after" the cursor in Normal-mode, for big paste-streams, is
not reliable: sometimes the text "after" the cursor ends up in the
middle of the pasted text. Maybe the cursor position is not updated?
To avoid weird behavior, always paste "before". Maybe nvim_put() or
vim.paste() can be fixed more properly later.
Problem: If multiple paste "chunks" are streamed, chunks after the
first line are pasted into the buffer.
Solution: Check for cmdline-mode for all chunks in a paste-stream.
- Workaround #10966: 'paste' option is not always reset.
- In any case there's not much reason to wait until phase=3, because
pasting in cmdline-mode skips lines after the first line (thus the
`:set paste .. :set nopaste` dance happens only ~once).
* longer timeout with first expect
* Wait for :term to be ready
Failure seen on quickbuild (note the "retry() attempts: 1"):
09:41:07,627 INFO - # test/functional/terminal/tui_spec.lua @ 437: TUI FocusGained/FocusLost in terminal-mode
09:41:07,627 INFO - not ok 2976 - TUI FocusGained/FocusLost in terminal-mode
09:41:07,627 INFO - # test/functional/terminal/tui_spec.lua @ 437
09:41:07,627 INFO - # Failure message: ./test/functional/helpers.lua:403:
09:41:07,627 INFO - # retry() attempts: 1
09:41:07,627 INFO - # ./test/functional/ui/screen.lua:579: Row 1 did not match.
09:41:07,627 INFO - # Expected:
09:41:07,627 INFO - # |*{1:r}eady $ |
09:41:07,627 INFO - # |[Process exited 0] |
09:41:07,627 INFO - # | |
09:41:07,627 INFO - # | |
09:41:07,627 INFO - # | |
09:41:07,627 INFO - # |gained |
09:41:07,628 INFO - # |{3:-- TERMINAL --} |
09:41:07,628 INFO - # Actual:
09:41:07,628 INFO - # |*{1: } |
09:41:07,628 INFO - # |{4:~ }|
09:41:07,628 INFO - # |{4:~ }|
09:41:07,628 INFO - # |{4:~ }|
09:41:07,628 INFO - # |{5:[No Name] }|
09:41:07,628 INFO - # | |
09:41:07,628 INFO - # |{3:-- TERMINAL --} |
09:41:07,628 INFO - #
09:41:07,628 INFO - # To print the expect() call that would assert the current screen state, use
09:41:07,628 INFO - # screen:snapshot_util(). In case of non-deterministic failures, use
09:41:07,628 INFO - # screen:redraw_debug() to show all intermediate screen states.
09:41:07,628 INFO - # stack traceback:
09:41:07,628 INFO - # ./test/functional/helpers.lua:403: in function 'retry'
09:41:07,628 INFO - # test/functional/terminal/tui_spec.lua:441: in function <test/functional/terminal/tui_spec.lua:437>
Adapt some tests for OpenBSD:
- scrollback_spec:
- seq(1) is not available on OpenBSD: we'd use jot(1).
- Instead use a (hopefully) portable awk(1) snippet.
- channels_spec
- job_spec
- tui_spec
- All "chunks" in a paste-stream should form a single undo-block. Side
effect of 7a85792884 was to create an undo-block for each chunk.
- Also: remove old :redraw force logic, irrelevant after 7a85792884.
Otherwise cursor and redraw code for normal and insert mode will not run. The
"tickle" workaround was used for this instead, and can now be removed.
The builtin vim.lua got the name
[string "-- Nvim-Lua stdlib: thevimmodule (:help l..."]
in error messages. Fix it to something reasonable.
- Introduce TRY_WRAP() until we have an *architectural* solution.
- TODO: bfredl idea: prepare error-handling at "top level" (nv_event).
- nvim_paste(): Revert luaeval() hack (see parent commit).
- With TRY_WRAP() in nvim_put(), 'nomodifiable' error now correctly
"bubbles up".
- nvim_paste(): Marshal through luaeval() instead of nvim_execute_lua()
because the latter seems to hide some errors.
- Handle 'nomodifiable' in `nvim_put()` explicitly.
- Require explicit `false` from `vim.paste()` in order to "cancel",
otherwise assume true ("continue").
- Show error only once per "paste stream".
- Drain remaining chunks until phase=3.
- Lay groundwork for "cancel".
- Constrain semantics of "cancel" to mean "client must stop"; it is
unrelated to presence of error(s).
Workaround this failure:
[ ERROR ] test/functional/terminal/tui_spec.lua @ 192: TUI paste: exactly 64 bytes
test/functional/helpers.lua:403:
retry() attempts: 478
test/functional/terminal/tui_spec.lua:201: Expected objects to be the same.
Passed in:
(table: 0x47cd77e8) {
*[1] = 'zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz endz' }
Expected:
(table: 0x47cd7830) {
*[1] = 'zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz end' }
This happens because `curwin->w_cursor.col` is sometimes decremented at
the end of `do_put`... because the editor is in Normal-mode instead of
the expected Insert-mode.
Caused by "typeahead race" (#10826): there may be queued input in the
main thread not yet processed, thus the editor mode (`State` global)
will be "wrong" during paste. Example: input "i" followed immediately by
a paste sequence:
i<start-paste>...<stop-paste>
^
"i" does not get processed in time, so the editor is in
Normal-mode instead of Insert-mode while handling the paste.
Attempted workarounds:
- vim.api.nvim_feedkeys('','x',false) in vim._paste()
- exec_normal() in tinput_wait_enqueue()
- LOOP_PROCESS_EVENTS(&main_loop,…,0) in tinput_wait_enqueue()
ref #10826
Fixes strange behavior where sometimes the buffer contents of a series
of paste chunks (vim._paste) would be out-of-order.
Now the tui_spec.lua screen-tests are much more reliable. But they still
sometimes fail because of off-by-one cursor (caused by "typeahead race"
resulting in wrong mode; fixed later in this patch-series).
Also fix V576: use width specification
> Incorrect format. Consider checking the third actual argument of the
> 'sscanf' function. It's dangerous to use string specifier without width
> specification. Buffer overflow is possible.
<Paste> is a 3-byte sequence and the beginning one or two bytes can appear at
the very end of the typeahead buffer. When this happens, we were exiting from
`vgetorpeek()` instead of reading more characters to see the complete sequence.
I think this should fix#7994 -- at least partially. Before this change, when I
paste exactly 64 characters into a freshly booted instance, I get what I pasted
plus the literal text "<Paste>" at the end. Nvim also stays in nopaste mode.
The attached test case fails in this manner without the code change.
Fix#7994
Problem: When we changed startup to wait for the TUI (like a remote UI),
we forgot to set os/input.c:global_fd. That used to be done by
input_start().
Solution: Initialize os/input.c:global_fd before initializing libtermkey
(termkey_new_abstract) so that tui_get_stty_erase() and
friends can inspect the correct fd.
fixes#10134close#10174
The test.functional.helpers and test.unit.helpers modules now include
all of the public functions from test.helpers, so there is no need to
separately require('test.helpers').
Previously, ordinary redraws were missing from terminal mode. Instead,
there was an async callback that invoked update_screen() on terminal
data regardless of mode (as if :redraw! was invoked by a timer).
This created some issues:
- async changes to an unrelated ordinary buffer were not always redrawn in
terminal mode
- screen cursor position was not properly updated in terminal mode (partial
fix, will be properly fixed in a follow up PR)
- ad-hoc logic was needed for interaction with special states such as
inccommand or horizontal wildmenu.
Instead redraw terminal mode just like any other state. This disables forced
redraws in cmdline mode, which were inconisent which async changes to
normal buffers (which are not redrawn in cmdline mode).
Before now, Nvim always degrades UI capabilities to the lowest-common
denominator. For example, if any connected UI has `ext_messages=false`
then `ext_messages=true` requested by any other connected UI is ignored.
Now `nvim_ui_attach()` supports `override=true`, which flips the
behavior: if any UI requests an `ext_*` UI capability then the
capability is enabled (and the legacy behavior is disabled).
Legacy UIs will be broken while a `override=true` UI is connected, but
it's useful for debugging: you can type into the TUI and observe the UI
events from another connected (UI) client. And the legacy UI will
"recover" after the `override=true` UI disconnects.
Example using pynvim:
>>> n.ui_attach(2048, 2048, rgb=True, override=True, ext_multigrid=True, ext_messages=True, ext_popupmenu=True)
>>> while True: n.next_message();
Problem: Using `:stopinsert` while in normal mode in a terminal buffer
prevents neovim from entering insert mode.
Solution: Move `stop_insert_mode = false` from terminal_check to
terminal_enter to be consistent with edit.c, as suggested by bfredl in
#9889.
Closes https://github.com/neovim/neovim/issues/9889.
Problem: Calling :stopinsert from RPC while in terminal-mode does not
go back to normal-mode.
Solution: Implement a check() handler for state_enter(), adapted from
insert_check().
Fix#7807
Previous approach skipped the test if the expected value matched the
default value ("dark"). New approach always checks, but uses retry() to
ignore potentially wrong 'background' before the terminal response is
handled.
If terminal response is received during startup, set 'background' from
a nested "one-shot" (once) VimEnter autocmd.
The previous not-so-clever "self-rescheduling" approach could cause
a long delay at startup (event-loop does not make forward progress).
fixes#9675
ref #9509
Problem: Relative cursor position is not calculated correctly.
Solution: Always set topline, also when window is one line only.
(Robert Webb) Add more info to getwininfo() for testing.
8fcb60f961
- Like Vim, use set_option_value() followed by reset_option_was_set().
- Do not use set_string_default(), so the default is predictable.
This affects `:set bg&`.
- Wait until end-of-startup (VimEnter) to handle the response. The
response is racey anyways, so timing is irrelevant. This allows
OptionSet to be triggered, unlike during startup.
