e6421d1b72 removed this bit from the
example:
```
-
- // Note that we're waiting until after we've read the output
- // to call `wait` on the process.
- // On macOS Catalina, waiting on the process seems to prevent
- // its output from making it into the pty.
- println!("child status: {:?}", child.wait().unwrap());
```
This commit revisits that and puts in place a differently horrible
solution for macos.
The issue is that if we don't put in a short sleep on macos, then
for a short lived process like `whoami` in this example, we end up
reading output like this:
```
; cargo run --example whoami
Compiling portable-pty v0.8.0 (/Users/wez/wez-personal/wezterm/pty)
Finished dev [unoptimized + debuginfo] target(s) in 0.60s
Running `/Users/wez/wez-personal/wezterm/target/debug/examples/whoami`
child status: ExitStatus { code: 0, signal: None }
output: \r\n^D\u{8}\u{8}wez\r\n%
```
where the EOT that we send on Drop somehow gets *prepended* to the output
that we read from the pty with a couple of BELs thrown in.
I'm not sure WTF is happening on macOS for that to occur; feels like
some kind of race wrt. process startup and initializing the pty in the
system.
The reader has to be started before we close it as well, otherwise
the same issue can occur.
This breaking API change allows us to explicitly generate EOF when the
taken writer is dropped.
The examples have been updated to show how to manage read, write
and waiting without deadlock for both linux and windows.
Need to confirm that this is still good on macOS, but my
confidence is high.
I've also removed ssh2 support from this crate as part of this
change. We haven't used it directly in wezterm in a long while
and removing it from here means that there is slightly less code
to keep compiling over and over.
refs: https://github.com/wez/wezterm/discussions/2392
refs: https://github.com/wez/wezterm/issues/1396
I'd forgotten that this was in here.
The recentish fixes to flush for various terminal queries
likely need this to be 100% good. Surprised this hasn't
come up as a bug already :-/
`wezterm start -- /etc/profile` would crash on macOS because
`/etc/profile` isn't executable.
This commit checks for executable access as a prereq for both the
path search and the absolute path cases and generates a non-crashing
error:
```
$ wezterm start -- /etc/profile
17:24:03.574 ERROR wezterm_gui > Unable to spawn /etc/profile because it doesn't exist on the filesystem or is not executable (EACCES: Permission denied); terminating
```
I think I may have inadvertently changed whether the arch portion
was included in the filename for stable releases.
Allow for that in the regex.
Remove debian 9 which is no longer supported.
closes: https://github.com/wez/wezterm/issues/2382
They pass this:
```
flatpak run --env=G_DEBUG=fatal-criticals org.freedesktop.appstream-glib validate assets/wezterm.appdata.xml
assets/wezterm.appdata.xml: OK
```
but break when building a flatpak
Previously, we'd unconditionally enable dual source blending for the
text foreground layer when rendering. That meant that if the user had
configured the fg color to include an alpha value it would get "stamped
through" the draw all the way to the background, making that whole pixel
take on that alpha value rather than allowing it to blend through the
way you might expect.
In prior releases that didn't matter, but since we now allow configuring
the fg color with alpha, and allow using escape sequences to set the fg
for a span to something with alpha, there is now a much higher chance of
something looking weird.
Dual source blending is only really needed for subpixel-aa and that
isn't enabled by default.
This commit changes the behavior to use regular alpha blending if the
main config (rather than a per-font override) hasn't set the freetype
load/render target to one that enables subpixel-aa.
That means that alpha channel values work as expected for fg color
by default.
If you want to enable subpixel-aa you need to enable it globally
and be aware that it will cause weirdness when trying to use alpha
channels for the fg text color.
The docs now also indicate this behavior.
This limitation could be removed by making text rendering significantly
more complex and I don't fancy doing that at this time.
Since the initial attach is async, we'd create the window at the
default/initial size and then never reconcile the size of the remote
tabs once they'd attached.
This commit introduces an event that allows the gui window to do that.
The action that it takes is to take the max width and height between
its current size and the size of a newly added tab and resizes to
that new size, if it changed.
refs: https://github.com/wez/wezterm/issues/2133
refs: https://github.com/wez/wezterm/issues/2351
Consolidate the attributes together rather than having them in separate
versioned sections so that it is a bit more readable.
Make a note about how attributes select from existing fonts rather than
apply styling effects to fonts.
refs: https://github.com/wez/wezterm/issues/2348
