Without this, `wzsh` will keep the terminal in raw mode between
line editor invocations, resulting in staggered/stairway output
for any spawned commands.
With the revised native windows console renderer using the various
console APIs more deeply, I've seen a couple of cases where those
API calls fail inside eg: wezterm running via the new pty machinery.
Using the virtual terminal APIs and the terminfo renderer is the
right thing to do in that case.
This commit probes for virtual terminal support and uses the builtin
xterm terminfo, unless the environment has
`TERMWIZ_BYPASS_VIRTUAL_TERMINAL=1` set. This allows forcing the
use of the windows console layer.
Some windows APIs have inclusive dimensions and some exclusive;
we were off by one for the height of the display which led to some
weirdness with eg: `sp` and the line editor.
When it comes to scrolling: if the scroll request is for the entire
viewport then we simply adjust the viewport; this is desirable because
it allows data to scroll back into the history in the native console.
This reduces flickering updates in the native windows console;
it works by taking a copy of the screen buffer, applying the
Change's to that buffer and then copying back to the console.
This is unfortunately a bit of a muddy commit and I'm too lazy to split
it up.
* Removed `Position::NoChange`; use `Position::Relative(0)` instead
* Added missing cursor positioning cases in the terminfo renderer
* Taught line editor about the cursor position when the line spans
multiple physical lines
* Taught the Windows input layer to process escape sequences for eg:
the arrow keys when running with virtual terminal enabled.
* Removed the hack that under-reported the terminal width; the hack
was present to make some aspects of rendering with the native windows
console logic easier, but it was getting in the way of the line
editor. This may well break something, but it fixed up the line
editor :-/
cc: @markbt
This commit changes the behavior on Windows:
* If $TERM is set and the `terminfo` crate is able to
successfully initialize and locate a terminfo database (this also
requires that $TERMINFO be set in the environment), then we'll
use the `TerminfoRenderer` instead of the `WindowsConsoleRenderer`
* If $TERM is set to `xterm-256color` and no terminfo database was
found, use our modern compiled-in copy (look in the `termwiz/data/`
directory for the source and compiled version of this) and use
the `TerminfoRenderer`.
* Otherwise use the `WindowsConsoleRenderer`.
In practice, this allows termwiz apps to opt in to features such as
true color support on Windows 10 build 1903 an later by setting their
`TERM=xterm-256color`. This happens to be the default behavior when
`ssh`ing in to a windows host via `wezterm`.
You can see the truecolor mode get applied by running this example:
```
cargo run --example widgets_basic --features widgets
```
with TERM set as above the background region that is painted by the app
will be a blueish/purplish color, but with it unset or set to something
invalid, it will fall back to black.
I'd like to eventually make termwiz assume the equivalent configuration
to `TERM=xterm-256color` by default on Windows 10 build 1903 and later,
but it's worth getting some feedback on how this works for clients such
as `streampager`.
cc: @quark-zju and @markbt
`cargo run --example widgets_basic --features widgets` changes the
cursor style but wasn't changing it back when exiting.
In addition, setting the cursor to Default was only restoring visibility
and not restoring the style.
I was running `hg log --config pager.pager=sp` and pressing space without
releasing it. After about 10k lines sp appears to deadlock. It seems sp uses a
single thread for both reading terminal events and sending wake events and it
sends too many wake events without reading the events.
Failing to write to the wake pipe due to EWOULDBLOCK does not seem to be a
problem - there are enough events in the pipe to wake up the other side.
Therefore let's just make wake_pipe_write nonblocking and treat EWOULDBLOCK as
a success.
Context: The stuck thread looks like:
#0 0x00007f32671ee237 in write () from /usr/lib/libc.so.6
#1 0x000055c466022823 in std::sys::unix::fd::FileDesc::write () at src/libstd/sys/unix/fd.rs:96
#2 std::sys::unix::net::Socket::write () at src/libstd/sys/unix/net.rs:276
#3 <&std::sys::unix::ext::net::UnixStream as std::io::Write>::write ()
at src/libstd/sys/unix/ext/net.rs:597
#4 <std::sys::unix::ext::net::UnixStream as std::io::Write>::write ()
at src/libstd/sys/unix/ext/net.rs:582
#5 0x000055c465d010a6 in termwiz::terminal::unix::UnixTerminalWaker::wake (self=0x7ffe6bd32de0)
at /home/quark/.cargo/git/checkouts/wezterm-6425bab852909cc8/ef1b836/termwiz/src/terminal/unix.rs:278
#6 0x000055c465a6c64b in streampager::event::EventSender::send_unique (self=0x7ffe6bd32dd0, event=...,
unique=0x7ffe6bd32de8) at src/event.rs:66
#7 0x000055c465a7e65a in streampager::display::start (term=..., term_caps=..., events=..., files=...,
error_files=..., progress=..., mode=streampager::config::FullScreenMode::Auto) at src/display.rs:295
#8 0x000055c465a453a7 in streampager::Pager::run (self=...) at src/lib.rs:171
#9 0x000055c465a0aced in sp::open_files (args=...) at src/bin/sp/main.rs:170
#10 0x000055c465a08e4f in sp::main () at src/bin/sp/main.rs:25
We need to set the terminal to blocking mode when we want poll_input
to block forever, otherwise we immediately receive WouldBlock error
response and quit the program.
`input_parser.decode_input_records` might not add anything to the input queue,
e.g. if the input event is one that is being ignored. In this case, we must
loop round and wait again for more input.
Remove the dance for appeasing the borrow checker. The borrow checker can
be appeased by borrowing the `input_queue` field directly.
Add two new `Change` variants: `ScrollRegionUp` and `ScrollRegionDown`, which
scroll part of the screen up or down by a number of lines.
On Unix, these are implemented using the `change_scroll_region` and
`parm_index`/`parm_rindex` terminfo capabilities if available. If `parm_index`
or `parm_rindex` are not available, but `scroll_forward` or `scroll_reverse`
are, then these are used repeatedly to get the same effect.
On Windows, these are implemented using `ScrollConsoleScreenBuffer`.
