Rather than just quitting the app and potentially silently killing off
a number of panes that might be running in other workspaces, we now
will pick one of those workspaces and activate it.
refs: #1531
This action causes the active workspace for the gui to change.
If the name is omitted a random name will be generated.
If the workspace doesn't exist, it will be be created.
The optional spawn parameter can be used to launch a specific
program into the new workspace; if omitted, the default prog
will be used.
The gui only supports a single active workspace. Switching workspaces
will repurpose existing gui windows and re-assign them to windows
in the new workspace, adjusting their size to fit those windows,
spawning new windows or closing unused windows as required.
The gui now exits when there are no panes in the active workspace,
rather than no panes at all.
refs: #1531
This commit updates the last input time for the active client
id when calling into local pane. That time is visible in the
`wezterm cli list-clients` output.
The mux now has a notion of which client is actively doing things.
This allows, for example, newly spawned windows to take on the
active workspace for a given client.
The gui now assigns a client id on startup, and sets the active
workspace to `default`.
The mux server temporarily overrides the active id to that of
the currently dispatching client when processing PDUs.
refs: https://github.com/wez/wezterm/issues/1531
Tidies up some code duplication within the mux protocol handler.
Move some of the logic into Mux, remove legacy Spawn Pdu to reduce
more duplication.
I want to dedup some of the similar logic that exists in the gui
spawn implementation as well in a follow up.
This is not exposed through any UX; the mux api allows setting
the workspace and propagating information about windows whose
workspace has changed.
Windows start with a blank workspace name.
This is just plumbing; nothing uses it yet.
refs: #1531
Define a way to compute a client ID and pass that through to the
mux server when verifying version compatibility.
Once associated, the session handler will keep some metadata
updated in the mux.
A new cli subcommand exposes the info:
```
; ./target/debug/wezterm cli list-clients
USER HOST PID CONNECTED IDLE WORKSPACE
wez mba.localdomain 52979 30.009225s 1.009225s
```
refs: #1531
If we know that the remote host is a unix system, and that it uses some
version of the posix shell, then we can adjust our command line to cd to
the requested directory (as set by OSC 7) and then exec the requested
command.
That's what SshDomain::assume_unix indicates and what this commit does.
If an ssh domain is set to use_multiplexer=false, it is now
possible to `wezterm connect` to it.
Previously, it was only possible to connect to domains that
used the mux client.
refs: https://github.com/wez/wezterm/issues/1456
They have their own versions of these options, and logically it doesn't
make sense to use the default_prog from the `local` domain with a wsl
domain.
refs: #1242
The idea is that we want to be able to spawn into wsl with the
convenience of a local domain, but without the awkwardness of
it having a different filesystem namespace.
It would also be great to be able to spawn a new tab or pane
in the same domain and pick up the cwd of the existing one.
The WslDomain allows the user to explicitly list WslDomains
and control eg: default shell, username and so on, but wezterm
will pre-fill a default list of domains based on the `wsl -l`
output that we were already using in the launcher menu.
The existing LocalDomain has been augmented to understand that
it may need to fixup a command invocation and that gives it
the opportunity to rewrite the command so that we can launch
it via `wsl.exe` and pass down the cwd and so on.
This same technique might be extensible to eg: docker instances
in the future.
This commit:
* Introduces `wsl_domains` config and its default list of wsl
distributions
* Creates LocalDomain instances from that list
* The launcher menu allows spawning a new tab via one of those domains
We need 100% of the info for it to work correctly, so this commit:
* Exposes the keyboard encoding mode via the Pane trait
* Adds the scan code to the RawKeyEvent
* Has the GUI perform the encoding if the keyboard is set that way
* Removes the basic encoder from termwiz in favor of the gui level one
The net result is that we bypass the Pane::key_up/Pane::key_down methods
in almost all cases when the encoding mode is set to win32-input-mode.
There is now a config option: allow_win32_input_mode that can be
used to prevent using this mode.
refs: #1509
Nothing generates them right now, and the mux client has no
way to represent them on the wire.
I'm considering constraining them to just win32 for now.
refs: https://github.com/wez/wezterm/issues/1509
When considering the fg process, we don't want a newly spawned
notepad.exe to show as the fg process in a cmd/pwsh pane, as it
runs async from the console and isn't attached to it.
We can extract the console handle from the process information and
use a 0 value handle to indicate win32 apps that are not attached
to any console.
We cannot compare console handle values directly: without probing
deeper into the handle we don't know that two differently valued
handles refer to different consoles, because a handle can be
duplicated into another with a different numeric value.
I noticed that sysinfo failed to yield info about 50% of the time on
macos!
Just go direct to the underlying system function; we don't need all
of the info that sysinfo collects in any case.
Previously, we would implicitly set it to the special SEQ_ZERO
value, but since that value always flags the row as changed,
it causes some over-invalidation issues downstream in wezterm.
This commit makes that parameter required, so that the code that
is creating a new Line always passes down the seqno from that event.
refs: #1472
ConPTY emits a sequence that sets the title to the name of the
program that is initially launched into it.
This commit tries to ignore that sequence in that circumstance,
so that the logic in b5d156c282
can more dynamically set the tab title.
If the pane title is the default `wezterm`, then return the
process basename instead. This makes the tab titles more useful
by default, although on Windows, conpty will set the title
to the initial executable path and defeat this.
Add `get_foreground_process_name` to both Pane and the lua wrapper.
Add `foreground_process_name` and `current_working_dir` fields to
`PaneInformation`. In order for those to be dynamically fetched,
switch the lua conversion for `PaneInformation` to be a UserData
with field access methods. It's a little more verbose but allows
us to lazily compute these two new fields.
refs: https://github.com/wez/wezterm/discussions/1421
refs: https://github.com/wez/wezterm/issues/915
refs: https://github.com/wez/wezterm/issues/876
Adds some plumbing to allow the GUI to implement a download handler
and connect that up for iterm2 image/file transfers that have their
inline property set to false.
Previously we'd just log an error.
Now we will by default download the file to the user's download
directory.
This behavior can be turned off via the new `allow_download_protocols`
configuration setting.
File transfers can be initiated on a remote host via the
https://iterm2.com/utilities/it2dl script.
When the download completes, a toast notification is shown that will
open the file when clicked.
refs: https://github.com/wez/wezterm/discussions/1450
Finally getting around to fixing this usability wart: this commit
changes the behavior of Window closing so that you can close a window
containing multiplexer panes without prompting and without killing
off those panes.
This is achieved through some plumbing:
* The mux can now advise Domains about an impending window closure,
giving them the opportunity to "do things" in readiness.
* The mux client domain informs the container ClientPane instances
to ignore the next Pane::kill call, which would otherwise inform
the mux server to kill the remote pane
* Pane:can_close_without_prompting now requires a CloseReason.
* ClientPane's can_close_without_prompting impl allows Window closing
without prompting on the assumption that the ignore-next-kill hack
above is working
refs: #848
refs: #917
refs: #1224
The mux client just returns a dummy reader, and some overlays
have panicking stubs: just allow for them to return None
instead of potentially spawning a useless thread.
This commit adds plumbing to support mapping the process tree to
lua objects which in turn allows a new `mux-is-process-stateful`
event to be defined by the user for finer control over closing
prompt behavior.
refs: #1412
In the mux layer, we have some code that takes a `Child` and then
does a bit of naughty reaching through the abstraction to get at
the pid/handle of the child so that we can send it signals even
if the child is itself mutably (and thus exclusively) borrowed
for the purposes of waiting.
That worked fine for local processes spawned in the mux, but we also
use LocalPane to wrap around arbitrary `Child`ren, such as Ssh,
that are not local and that don't have a local process id, which
meant that this hack wouldn't work for them.
To make things a bit worse, those ssh ptys were used to ssh2 days
where we didn't have a way to signal the remote process and just
did nothing, leading to confusing situations such as
https://github.com/wez/wezterm/issues/1197
This commit graduates the hack mentioned in the first paragraph
to its own ChildKiller trait. This makes the concept of waiting
for the Child distinct from signalling it and explicitly allows
getting a separate object that can be used for signalling.
With that in place, we're forced to implement something appropriate
for the ssh pty implementations; one in the pty crate itself,
one in wezterm-ssh and the wrapper that we use in the mux crate.
The upshot of this is that the `CloseCurrentPane` action now operates
correctly on panes that were the result of split operations.
This is a fairly far-reaching commit. The idea is:
* Introduce a unicode_version config that specifies the default level
of unicode conformance for each newly created Terminal (each Pane)
* The unicode_version is passed down to the `grapheme_column_width`
function which interprets the width based on the version
* `Cell` records the width so that later calculations don't need to
know the unicode version
In a subsequent diff, I will introduce an escape sequence that allows
setting/pushing/popping the unicode version so that it can be overridden
via eg: a shell alias prior to launching an application that uses a
different version of unicode from the default.
This approach allows output from multiple applications with differing
understanding of unicode to coexist on the same screen a little more
sanely.
Note that the default `unicode_version` is set to 9, which means that
emoji presentation selectors are now by-default ignored. This was
selected to better match the level of support in widely deployed
applications.
I expect to raise that default version in the future.
Also worth noting: there are a number of callers of
`unicode_column_width` in things like overlays and lua helper functions
that pass `None` for the unicode version: these will assume the latest
known-to-wezterm/termwiz version of unicode to be desired. If those
overlays do things with emoji presentation selectors, then there may be
some alignment artifacts. That can be tackled in a follow up commit.
refs: #1231
refs: #997
* mux: unzoom when switching panes
Add `unzoom_on_switch_pane` config option:
When switching to another pane with ActivatePaneDirection, if the
current pane is zoomed, unzoom and then switch instead of doing nothing.
* Apply suggestions from code review
Co-authored-by: Wez Furlong <wez@wezfurlong.org>
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
