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).
<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').
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();
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
- 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.
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
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.
