| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
| |
User config may set $PS1 for a colored prompt.
It breaks the screen tests.
|
| |
|
|
|
| |
The commit summary maybe does not make sense, but calling a function
that does not wait on anything `wait()` makes even less sense.
|
| |
|
|
| |
ref #11004
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
It is perfectly fine and expected to detach from the screen just by
the UI disconnecting from nvim or exiting nvim. Just keep detach() in
screen_basic_spec, to get some coverage of the detach method itself.
This avoids hang on failure in many situations (though one could argue
that detach() should be "fast", or at least "as fast as resize",
which works in press-return already).
Never use detach() just to change the size of the screen, try_resize()
method exists for that specifically.
|
| |
|
|
|
|
| |
Using `screen:expect` with the complete grid appears to fix its
flakiness.
Fixes https://github.com/neovim/neovim/issues/10723.
|
| |
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
| |
TermOpen autocmd may set local 'scrollback' to -1, this needs to be
adjusted as in on_scrollback_option_changed().
fixes #9588 (OOM, out of memory)
|
| |
|
|
|
|
|
|
|
| |
Makes the 'scrollback' option more consistent (same default for all buffers) and future-proof.
- Default to -1 for all buffers, but treat it as an implementation detail.
- Document range of 1 - 100_000.
- New terminal buffer by default sets scrollback=10_000 if the global default is -1.
- Existing terminal buffer: On entering terminal-mode or on refresh, if the user explicitly did `:set[local] scbk=-1`, the local value goes to 100_000 (max). (This is undocumented on purpose. Users should work with explicit values in the range of 1-100_000.)
|
| |
|
|
|
| |
closes #8324
closes #8556
|
| |
|
|
|
| |
- fix: Use "set PROMPT=$" trick to satisfy screen:expect{any='%$'}
- speedup: Use cmd.exe instead of powershell.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
tty-test.exe causes abnormal termination with low repeatability, try
changing it so as not to use SIGWINCH.
|
| | |
|
| |
|
|
| |
Avoids a spurious :loadview error.
|
| |
|
|
|
|
|
|
|
|
| |
Hope this will make people using feed_command less likely: this hides bugs.
Already found at least two:
1. msgpackparse() will show internal error: hash_add() in case of duplicate
keys, though it will still work correctly. Currently silenced.
2. ttimeoutlen was spelled incorrectly, resulting in option not being set when
expected. Test was still functioning somehow though. Currently fixed.
|
| |
|
|
|
|
|
|
|
|
|
| |
Make the 'scrollback' option work like most other buffer-local options:
- `:set scrollback=x` sets the global and local value
- `:setglobal scrollback=x` sets only the global default
- new terminal buffers inherit the global
Normal buffers are still always -1, and :setlocal there is an error.
Closes #6337
|
| | |
|
| | |
|
| |
|
|
| |
Closes #2637
|
| |\
| |
| | |
Enable functional tests in Appveyor
|
| | | |
|
| |/
|
|
| |
update screen.lua to use new style nvim_ui_attach
|
| | |
|
| |
|
|
|
|
| |
It is otherwise impossible to determine which test failed sanitizer/valgrind
check. test/functional/helpers.lua module return was changed so that tests which
do not provide after_each function to get new check will automatically fail.
|
| |
|
|
|
|
|
|
| |
A terminal buffer now exits with: [Process exited <return value>]
You can hook into it. E.g. :au TermClose * call feedkeys('<cr>')
Closes #2293.
|
| |
|
|
|
| |
Since close_cb may free the terminal structure, save the "wipe" flag before
calling it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Old behaviour: termopen('cmd') would run `&shell &shcf "cmd"`, which
caused the functional tests to fail on some systems due to the process
not "owning" the terminal. Also, it is inconsistent with jobstart().
Modify termopen() so that &shell is not invoked, but maintain the old
behaviour with :terminal. Factor the common code for building the
argument vector from jobstart() and modify the functional tests to call
termopen() instead of :terminal (fixes #2354).
Also:
* Add a 'name' option for termopen() so that `:terminal {cmd}` produces
a buffer named "term//{cwd}/{cmd}" and termopen() users can customize
the name.
* Update the documentation.
* Add functional tests for `:terminal` sinse its behaviour now differs
from termopen(). Add "test/functional/fixtures/shell-test.c" and move
"test/functional/job/tty-test.c" there, too.
Helped-by: Justin M. Keyes <@justinmk>
|
|
|
- Modify tty-test to allow easier control over the terminal
- Add a new directory with various terminal tests/specifications
- Remove a pending job/pty test.
- Flush stdout in Screen:snapshot_util() (avoid waiting for the test to finish)
- Replace libuv sigwinch watcher by a sigaction handler. libuv randomly fails to
deliver signals on OSX. Might be related to the problem fixed by
@bbcddc55ee1e5605657592644be0102ed3a5f104 (under the hoods, libuv uses a pipe
to deliver signals to the main thread, which might be blocking in some
situations)
|
