Terminal now maintains a sequence number that increments
for each Action that is applied to it.
Changes to lines are tagged with the current sequence number.
This makes it a bit easier to reason about when an individual
line has changed relative to some point in "time"; the consumer
of the terminal can sample the current sequence number and then
can later determine which lines have changed since that point
in time.
refs: https://github.com/wez/wezterm/issues/867
There are some cases where we can print that status before we've
fully drained the output; it's slightly nicer to ensure that
we have an "atomic" line of its own for that, to minimize
the crappiness of the resulting output.
Previously, we'd use a 1MB buffer both to read the output from the
associated pty (blocking), and the same size buffer again to do the
non-blocking read on top of that.
For pathological cases (eg: cat 100MB+ files), we could build a
resulting `Vec<Action>` with over 1mm entries and it could take as much
as 100ms to apply those actions to the terminal model.
This meant that the output could stutter/lag and appear to be processed
more slowly.
This commit introduces a configuration value for the buffer size for the
second stage, and makes it 10KB in size. This helps to constrain the
size of the Action vec and keeps the incremental processing costs down,
while still managing the same throughput.
This commit hooks up DECRQM so that we can report that we implement
synchronized updates, and then refines the code that manages sending
data to the terminal model; the first cut at synchronized updates
was a bit simplistic, and now we make a point of "flushing" pending
actions when we start a sync point, and again as soon as we release
the sync point.
This smooths out the jaggies around the orca that I mentioned in
dcbbda7702
and while testing this, I realized that recent parser changes had
mangled processing bundled dec private mode sequences where multiple
modes were specified in the same overall escape sequence. I've
added the missing unit test case for this and made that work again.
refs: https://github.com/wez/wezterm/issues/955
refs: https://github.com/wez/wezterm/issues/882
This implementation doesn't include a timeout, but should be
recoverable via a SoftReset.
There's no query response either: I think I'm missing DECRQM
entirely at the moment.
refs: https://github.com/wez/wezterm/issues/882
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.
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
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
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
The issue is that the pane was only removed from the tab when explicitly
closed, leaving it to be later detected and flushed.
However, in the meantime, when performing eg: cursor blink maintenance,
if the set of panes in the tab is empty then the window would close.
The resolution is to ask the mux (rather than the tab) to kill the pane,
so that the cascading closure of the tab causes the window's active
tab to reference the correct remaining tab.
refs: #890
Expand on the changes in 3f6ff534d3,
this makes them more general and so that they can be used on unix
systems.
That in turn helps to tackle https://github.com/wez/wezterm/issues/839,
wherein `sleep 300 & disown ; exit` would linger until EOF is detected,
rather than triggering as soon as the child process terminated.
For whatever reason, that would only manifest on linux (and not macos).
Same vein as 8931afba5cee07ab12990f06c2ff34d6f8426b19; the auth
window could sometimes get stuck until an input event was sent
to it.
Wire up a mux event so that the window can close itself.
When the client connected to an empty remote mux, it would allocate an
empty window and then spawn a new tab into it.
Meanwhile, the authentication window would close and trigger a prune of
all empty windows, causing the in-flight spawn to fail because its
destination window was removed.
This commit defers window pruning while Activity is in progress;
the MuxWindowBuilder has an associated Activity count.
in the same vein as d657721163
this commit introduces more assertive signalling from the remote
mux when a pane is closed so that the client can update.
Similar to 3f6ff534d3, we need to
tickle the mux to detect when the session terminates.
In this case we can relatively simply schedule an async wait without
spawning an additional thread.
Since removing the regular periodic background tasks, we're now
prone to not noticing child processes exiting.
This commit explicictly schedules a thread to do that on Windows
so that we can close a tab as soon as it exits.
This kill/wait was added to workaround fish being weird on macos.
This is accidentally exponential as the pty layer already loops,
so we don't need to also loop here.
refs: https://github.com/wez/wezterm/issues/774
The status information now explains the exit status and the
exit_behavior, as well as links to the docs on exit_behavior.
refs: https://github.com/wez/wezterm/issues/795
As part of reducing the amount of regularly scheduled stuff wezterm
does in the background, this commit restructures how an empty mux
is detected; now when the mux prunes dead windows it will emit
an Empty event.
The Activity type will now schedule a prune when it is dropped,
which will clean up and trigger the Empty event.
refs: https://github.com/wez/wezterm/issues/770
This got a bit broken by the fix for https://github.com/wez/wezterm/issues/714
since we can be handed a range of logical line fragments, we should
test each of them to find our matching result.
Also, improve the logic for constraining the length when looking
backwards.
the binary search would falsely extend the end of the match
to the start of the subsequent match for the wrapped line case.
The resolution is to emit a coordinate for the newline that we
add to the haystack between the wrapped lines.
closes: https://github.com/wez/wezterm/issues/732
* Make alphabet and patterns configurable
* add docs
* Enhance scrollback search to support regex captures so that
searching for eg: `fo(o)` will select the last `o` in `foo`.
refs: https://github.com/wez/wezterm/issues/732
This tidies up how we pass the ssh config to the connection ui
logic, by moving the ssh_config setup to the two callers.
A couple of notable adjustments:
* SshDomain::username is now optional; it will default to the
values computed by the ssh config file loader
* no_agent_auth value wasn't hooked up to anything, but now it is
refs: https://github.com/wez/wezterm/issues/730
We weren't fixing up the active tab position correctly after removing
a tab. I think this bug crept in around the ActivateLastTab changes.
We now try harder to set active idx back to the tab that was active
prior to the remove, and ensure that we set the active index to
something within range if it was the active tab that was removed.
Refs: https://github.com/wez/wezterm/issues/690
We were handling the case where the chunk intersected a multibyte
boundary after the first chunk, but not for the first chunk itself.
Refactor the code so that we use the same chunk splitting logic
for both of those cases.
refs: https://github.com/wez/wezterm/issues/668
This function could return 1 more line than was requested in the case
where resizing had caused long lines to rewrap.
That extra line would cause the partial bottom row of the quads to
populated with bogus data and rendered over the top of the background
fill.
The resolution is to stop populating lines once we've reached the
upper bound based on the input range.
refs: https://github.com/wez/wezterm/issues/605
