- Always load files when cleaning up jumplist.
- For Shada: avoids writing duplicate entries, which happens when you read
from a shada file with duplicate entries (merging the jumplist while
writing sometimes produces duplicate entries, bug?) and then write right
away (i.e.: without any `:jumps`, `getjumplist()`, or any jump movement,
that is: nothing that calls `cleanup_jumplist` with `loadfiles == true`).
- For Context: avoids non-idempotent behavior for the same reason (i.e.:
first call to `shada_encode_jumps` does not remove duplicate entries).
- Do not set pcmark when dumping jumplist for Context.
- Retrieving current Context shouldn't add an entry to the jumplist
(which will be removed by a subsequent `cleanup_jumplist` anyway, i.e.:
tail entry matching current position), just act like `getjumplist` for
instance.
Problem: If a job exits while waiting on another job, the on_exit
handler is queued but f_jobwait() skips it.
Solution: Always do process_wait(), so that handlers are run during
f_jobwait().
fix#8302
Test case:
$ BUSTED_ARGS="--repeat=2000 --no-keep-going" TEST_FILE=test/functional/core/job_spec.lua TEST_FILTER=waiting make functionaltest
Failure example (macOS CI):
FAILED test/functional/core/job_spec.lua: jobs jobwait will run callbacks while waiting
test/functional/core/job_spec.lua:606: Expected objects to be the same.
Passed in:
(table: 0x1be77c80) {
[1] = 'notification'
[2] = 'wait'
*[3] = {
*[1] = 3 } }
Expected:
(table: 0x1be77d10) {
[1] = 'notification'
[2] = 'wait'
*[3] = {
*[1] = 4 } }
stack traceback:
test/functional/core/job_spec.lua:606: in function <test/functional/core/job_spec.lua:583
[ ERROR ] test/functional\ui\wildmode_spec.lua @ 84: 'wildmenu' is preserved during :terminal activity
test\functional\ui\screen.lua:587: Row 1 did not match.
Expected:
|*:sign |
|*define place |
|*jump undefine |
|*list unplace |
|*:sign ^ |
Actual:
|*0: !terminal |
|* |
|*^ |
|*~ |
|* |
stack traceback:
test\functional\ui\screen.lua:587: in function '_wait'
test\functional\ui\screen.lua:370: in function 'expect'
test/functional\ui\wildmode_spec.lua:22: in function 'expect_stay_unchanged'
test/functional\ui\wildmode_spec.lua:103: in function <test/functional\ui\wildmode_spec.lua:84>
Test sometimes fails on macOS CI:
FAILED test/functional/core/job_spec.lua: jobs jobwait will run callbacks while waiting
test/functional/core/job_spec.lua:606: Expected objects to be the same.
Passed in:
(table: 0x1be77c80) {
[1] = 'notification'
[2] = 'wait'
*[3] = {
*[1] = 3 } }
Expected:
(table: 0x1be77d10) {
[1] = 'notification'
[2] = 'wait'
*[3] = {
*[1] = 4 } }
stack traceback:
test/functional/core/job_spec.lua:606: in function <test/functional/core/job_spec.lua:583
Change the test to check if all jobs are starting, not only exiting.
luassert uses 3 by default, which is often not enough.
Instead of documenting how to increase it, let's use a more fitting
(sane) default of 100 levels.
Currently `nvim -u NORC --cmd "set display-=msgsep"` will still allocate the
message grid and remove it just afterwards. While inefficient, we must
make sure update_screen() re-validates the default_grid completely when
this happens.
Fix some invalid logic: don't reallocate msg_grid on resize when the grid is not
used.
Elide a too early ui_flush() on startup, which caused an invalid cursor
position to be used.
For debugging failures like:
test/functional/helpers.lua:240: test/functional/ui/screen.lua:898:
bad argument #1 to 'unpack' (table expected, got number)
test/functional/helpers.lua:240: test/functional/ui/screen.lua:708:
attempt to index local 'item' (a number value)
ref #10804
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
NB: the `!(flags & SOPT_GLOBAL)` exception is for 'statusline'.
Because `:set statusline=...` sets the global value for _all_ windows,
`:setlocal` is the best we can do there. This is a one-of-a-kind option
that doesn't work like any other option.
- 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.
REP_NODELAY was added because REP delayed too much. This changes REP to
only add a delay on every 100th line instead.
This helps to cover the additional pulse steps with
out_data_decide_throttle, which would have required to change
REP_NODELAY anyway.
- 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).
