aboutsummaryrefslogtreecommitdiff
path: root/test/functional/terminal/tui_spec.lua
Commit message (Collapse)AuthorAge
...
* tests: fix flaky "TUI FocusGained/FocusLost in terminal-mode" #10754Daniel Hahler2019-09-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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>
* test: add tests for pager glitches and crashesBjörn Linse2019-09-06
|
* test/uname(): always lowercaseJustin M. Keyes2019-09-01
|
* CI/OpenBSD: run functional testsEdd Barrett2019-09-01
| | | | | | | | | | | 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
* paste: one undo-block per streamJustin M. Keyes2019-09-02
| | | | | | - 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.
* test/ui: update tests for new msg_grid implementationBjörn Linse2019-09-01
|
* tui/input: defer nvim_paste properly.Björn Linse2019-08-31
| | | | | | | | | 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.
* test: vim.paste() cancelJustin M. Keyes2019-08-30
|
* paste: break lines at CR, CRLF #10877Justin M. Keyes2019-08-29
| | | | | | Some terminals helpfully translate \n to \r. fix #10872 ref #10223
* API: TRY_WRAP() for "abort-causing non-exception errors"Justin M. Keyes2019-08-28
| | | | | | | | - 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".
* paste: handle 'nomodifiable'Justin M. Keyes2019-08-27
| | | | | | | | - 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").
* paste: make vim.paste() "public"Justin M. Keyes2019-08-27
|
* paste: handle vim.paste() failureJustin M. Keyes2019-08-27
| | | | | | | | - 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).
* paste: implement redo (AKA dot-repeat)Justin M. Keyes2019-08-27
| | | | | | - Normal-mode redo idiom(?): prepend "i" and append ESC. - Insert-mode only needs AppendToRedobuffLit(). - Cmdline-mode: only paste the first line.
* paste: insert text "before" cursor in Insert-modeJustin M. Keyes2019-08-27
|
* API: nvim_pasteJustin M. Keyes2019-08-27
|
* paste: workaround typeahead raceJustin M. Keyes2019-08-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* API: nvim_put: always PUT_CURSENDJustin M. Keyes2019-08-27
| | | | | | | | | 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).
* test/tui_spec: connect to child sessionJustin M. Keyes2019-08-27
|
* paste: edge-case: handle EOL at end-of-bufferJustin M. Keyes2019-08-27
| | | | This is "readfile()-style", see also ":help channel-lines".
* paste: testJustin M. Keyes2019-08-27
|
* paste: use nvim_put()Justin M. Keyes2019-08-27
|
* paste: fixup testsJustin M. Keyes2019-08-27
|
* TUI/paste: always flush on paste mode-changeJustin M. Keyes2019-08-27
| | | | | | 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.
* tests: make TERM=interix test pending (#10576)Daniel Hahler2019-07-22
| | | | Ref: https://github.com/neovim/neovim/issues/10179 Ref: https://github.com/neovim/neovim/pull/9494
* tests: fix/improve "TUI background color" tests (#10229)Daniel Hahler2019-07-03
| | | | - Ensure the opposite of the expected bg is active. - Improves performance: 1.2s instead of 4.5s.
* getchar: Handle incomplete <Paste> in typeahead buffer #10311Alan Wu2019-06-24
| | | | | | | | | | | | <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
* tui: support rgba background detection (#10205)Harm te Hennepe2019-06-13
| | | Fixes https://github.com/neovim/neovim/issues/10159.
* TUI: set os/input.c:global_fd to input->in_fd #10174erw72019-06-10
| | | | | | | | | | | | | 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
* test: remove use of require('test.helpers')Justin M. Keyes2019-05-18
| | | | | | 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').
* UI/nvim_ui_attach(): add `override` optionJustin M. Keyes2019-05-09
| | | | | | | | | | | | | | | | | | | | 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();
* test: simplify TUI bg-detection testJustin M. Keyes2019-03-15
| | | | | | | 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.
* TUI/background detection: hook into VimEnter eventJustin M. Keyes2019-03-11
| | | | | | | | | | | 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
* TUI: rework background-color detectionJustin M. Keyes2019-02-22
| | | | | | | | | - 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.
* Merge #5027 'TUI: detect background color'Justin M. Keyes2019-02-17
|\
| * Merge #5027 'TUI: detect background color'Justin M. Keyes2019-01-17
| |\
| | * Add tests for terminal background detectionJosh Triplett2016-07-24
| | |
* | | UI: always use contrete colors for default_colors_setBjörn Linse2019-02-05
| | | | | | | | | | | | | | | But add an escape hatch needed for external TUI, so it still can use terminal emulator defaults.
* | | :terminal : set topline based on window height #8325Andrew Pyatkov2019-01-29
|/ / | | | | | | | | closes #8324 closes #8556
* | multigrid: add multigrid screen testsUtkarsh Maheshwari2018-12-31
| |
* | multigrid: add multigrid support to test infrastructureBjörn Linse2018-12-31
| | | | | | | | make Screen explicitly tied to its session
* | test: win/TUI builtin terminfosJustin M. Keyes2018-12-28
| |
* | highlight: Fix missing .rgb_sp_color in initializers (#9287)Justin M. Keyes2018-11-30
| | | | | | | | | | | | | | terminal_get_line_attributes() had this bug for a long time, though it likely had no effect visible to users. ref #9028 ref 60f845ca55a1
* | defaults: background=dark #2894 (#9205)Justin M. Keyes2018-11-20
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | tests: improve robustness of immediate successes in screen testsBjörn Linse2018-10-15
| |
* | test: replace wait() with pre-assertion in assert_term_colorsBjörn Linse2018-10-06
| |
* | ui: rename ext_newgrid to ext_linegridBjörn Linse2018-10-01
| |
* | tests: introduce screen:expect{...} formBjörn Linse2018-08-27
| |
* | ui: use line-based rather than char-based updates in screen.cBjörn Linse2018-07-21
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | nvim_list_uis: include channel idBjörn Linse2018-06-01
| |
generated by cgit (git 2.34.1) at 2025-04-29 13:17:32 +0000