| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
|
|
|
|
|
| |
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 a9e2bae0eb69 (insert-before-cursor).
NB: Dot-repeat needs to match the original action. Since a9e2bae0eb69
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>
|
|
|
|
| |
Eliminate `expect_err` in favor of `pcall_err` + `eq` or `matches`.
|
| |
|
|
|
|
| |
Ref: #10804
Ref: b64af88
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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 7a8579288424 was to create an undo-block for each chunk.
- Also: remove old :redraw force logic, irrelevant after 7a8579288424.
|
|\
| |
| | |
Dedicated message grid.
|
| | |
|
|/ |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
Some terminals helpfully translate \n to \r.
fix #10872
ref #10223
|
|
|
|
|
|
|
|
| |
- 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).
|
|
|
|
|
|
| |
- Normal-mode redo idiom(?): prepend "i" and append ESC.
- Insert-mode only needs AppendToRedobuffLit().
- Cmdline-mode: only paste the first line.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
| |
This is "readfile()-style", see also ":help channel-lines".
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Flush input before entering, not only when leaving, paste mode. Else
there could be pending input which will erroneously be sent to the paste
handler.
|
| |
|
| |
|
| |
|
|
|
|
| |
Ref: https://github.com/neovim/neovim/issues/10179
Ref: https://github.com/neovim/neovim/pull/9494
|
|
|
|
|
|
|
| |
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.
|
|
|
| |
Closes https://github.com/neovim/neovim/pull/4766.
|
|
|
|
| |
- Ensure the opposite of the expected bg is active.
- Improves performance: 1.2s instead of 4.5s.
|
|
|
|
|
|
| |
`retry()` would only try it three times (waiting for 20ms in between),
despite the large timeout.
Fixes https://github.com/neovim/neovim/issues/10265.
|
|
|
|
|
|
|
|
|
|
|
|
| |
<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
|
|
|
| |
Fixes https://github.com/neovim/neovim/issues/10159.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 #10134
close #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').
|
|\
| |
| | |
make terminal state redraw like any other state
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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();
|