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).
Problem: The a: dict is not immutable as documented.
Solution: Make the a:dict immutable, add a test. (Ozaki Kiichi, Yasuhiro
Matsumoto, closesvim/vim#3929)
31b816042f
Inspired by quickbuild failure, where `g:val` was increased already:
20:07:04,227 INFO - not ok 1164 - timers works with repeat two
20:07:04,227 INFO - # test/functional/eval/timer_spec.lua @ 36
20:07:04,227 INFO - # Failure message: test/functional/eval/timer_spec.lua:38: Expected objects to be the same.
20:07:04,227 INFO - # Passed in:
20:07:04,227 INFO - # (number) 1
20:07:04,227 INFO - # Expected:
20:07:04,227 INFO - # (number) 0
20:07:04,227 INFO - # stack traceback:
20:07:04,227 INFO - # test/functional/eval/timer_spec.lua:38: in function <test/functional/eval/timer_spec.lua:36>
Uses a pattern of `eq()`ing `timer_start` and `g:val` in the same `eval`
call, and decreases timeouts in general.
Improves runtime from ~5s to <2s.
