Looking at #900; the unconditional directory change on startup
is "bad" because it only happens on Windows.
This commit removes it and instead puts the logic into the pty
layer to match the unix behavior.
The behavior is:
* If the command specifies the cwd, use that.
* Otherwise, use the home directory
This commit causes a window-config-reloaded event to trigger
when the appearance (dark/light mode) is changed on macos.
It also arranges to propagate the window level config to newly
spawned panes and tabs, created both via the gui and via the
CLI/mux interface.
refs: https://github.com/wez/wezterm/issues/894
refs: https://github.com/wez/wezterm/issues/806
This allows window-level config overrides to apply
to panes contained within the window.
For instance, this allows setting a window-level
color scheme.
Add the third device attributes (DA3) query+reply,
eliminating "unknown/unspecified CSI" error. Like
XTerm, simply reply with zeroes as opposed to site
codes or unique IDs.
https://vt100.net/docs/vt510-rm/DA3.html
I saw this in the stderr logs when the connection was offline:
```
2021-07-17T01:54:28.036Z ERROR wezterm_ssh::session > Failed to write data to channel: Failure while draining incoming flow. Now
what?
2021-07-17T01:54:28.036Z ERROR wezterm_ssh::session > Failed to write data to channel: Failure while draining incoming flow. Now
what?
2021-07-17T01:54:28.142Z ERROR wezterm_ssh::session > Failed to write data to channel: Failure while draining incoming flow. Now
what?
```
This commit propagates the error rather than logging and ignoring it.
In addition, remove a couple of sources of blocking or panicking
that are now unmasked by this.
Possibly the root cause of https://github.com/wez/wezterm/issues/857
While looking at https://github.com/wez/wezterm/issues/945 I noticed
that mouse moves were being considered to be drag events even though
no mouse buttons were held down.
Test scenario is:
* Create a split
* in each pane run: `printf "\e[?1004h" ; od -c`
* Focus the panes, focus another window, and focus the window again
* The I and O events appear in the panes when changing their focus.
* Previously, only the active pane would get focus events when the
window focus changed.
refs: https://github.com/wez/wezterm/issues/941
* [terminfo] add smxx/rmxx, purge blink
Testing with WezTerm nightly indicates no blink support
available through the xterm \E[5m, and I didn't see any
support in the code -- purge it. smxx and rmxx, meanwhile,
have been added to indicate support for struck text.
* restore blink
Co-authored-by: Wez Furlong <wez@wezfurlong.org>
Test scenario is `cat`ing the public domain wiki text data from
http://cs.fit.edu/~mmahoney/compression/enwik8.zip in the terminal;
that file is 96M in size.
`time cat ~/Downloads/enwik8.wiki`
Prior to this change, depending on the OS, the time to cat the file
could be several minutes.
Digging in, the bottleneck appears to be that there isn't sufficient
parallelism between the reader and the parser, which means that the
rate of reading data is constrained by how long it takes to parse
and render a frame.
This commit switches away from using a synchronized vecdeque to
effectively create a non-blocking pipe, to "simply" using a socketpair
with a larger buffer size.
We now do blocking pty read -> write to socketpair in the reader
thread, and then read socketpair -> parse in the other.
The key difference between before and after being that the pty read
can continue to read and accumulate data (with an upper bound, so
that CTRL-C is still responsive) while we're parsing and rendering
a frame.
This increases the throughput for this scenario, bringing it down
from ~3:30 to ~17 seconds on this Ryzen 2700X system.
refs: https://github.com/wez/wezterm/issues/927
I added this originally thinking that it would make it easier to resolve
https://github.com/wez/wezterm/issues/695 and to integrate wgpu support,
but it's the cause of https://github.com/wez/wezterm/issues/922 so let's
take it out and more directly connect the window events to those in the
terminal.
This commit likely breaks mac and windows; pushing it so that I can
check it out and verify on those systems.
The common palette indices are in the main cell attributes.
Using true color will allocate fat storage.
This allows reducing the Cell size from 32 -> 24 across the
implementation of storing 10 bpc color (it peaked at 40 in
the last couple of commits).
Adding an edge from wezterm-ssh -> async_ossl causes the
openssl vendoring feature selection logic to trigger, which
in turn allows `cargo build -p window --examples` to succeed
again on macos.
