The future won't ever complete if you don't connect the waker
from the context!
Prove this out by making the windowops functions async and
verifying them in the async example
I introduced this issue with the recent rate limiting changes. If we
generated sufficient events to fill the pipe buffer and trigger an
EAGAIN on the write side of the pipe, we'd end up in a state where epoll
would continually wake us up to deal with it, but because we gated
reading from the pipe on having entries in the queue we could decide
that there was nothing to do and leave the pipe unread.
This commit adjusts things so that we always try to read some data from
it.
This is OK because we're using the pipe to knock the main thread out of
a sleep rather than as the definitive count of events.
It will pass the message text to the shell without proper quoting
which results in it running all sorts of garbage depending on
the message you're trying to display.
Very scary!
refs: https://github.com/jdm/tinyfiledialogs-rs/issues/19
I'm seeing occasional 100% cpu usage on my linux system and I'm
not sure if its just because I'm running a stale binary.
I added this (commented out in this commit, but live on my local
system) debug print to help understand it.
I've found that 10_000/s strikes a reasonable balance between
output speed and the ability to interrupt the output.
Refs: https://github.com/wez/wezterm/issues/65
The `SpawnQueue::run_impl` would loop until it had exhausted
all queued items. This prevents returning to the main loop
and resulted in the UI hanging while eg: `yes` was running,
and could also block accepting keyboard input, which is
pretty bad.
In addition, the queue implementation could fill up a pipe
and block the write side while it held a lock, which in
turn would prevent the read side from making room for the
write to succeed!
This commit changes the behavior on linux to change the wakeup
behavior of the queue from having a 1:1 relationship between
enqueue:wakeup to n:m where n and m are both >= 1. This is
sufficient to wake a sleeping gui thread. The gui thread
can then pop and process a single item at a time, interleaved
with dispatching the gui events.
The result is a bit more responsive, however, there is no
backpressure from the gui to the read side, so if the read
side is eating 2MB/s of data and the GUI side is processing
less than this, then an interrupt signal may still take a
few seconds to take effect.
I have mixed feelings about adding backpressure, because
I'm not sure that it is worth actually rendering all of
the parsed output text when there is a lot of it.
I need to follow up and verify these changes on macOS
and Windows too.
Refs: https://github.com/wez/wezterm/issues/65
We need to chunk the data that we read from the child otherwise
we may potentially try to admit more data in a single action
than the ratelimiter will ever allow (eg: if we read 4k of data
and the limit is 100 bytes per second, we can never send that
4k of data in a single write).
Our handling of that situation was not good: we'd panic and kill
the background thread that was reading the data, but the rest
of the app was still running.
This commit upgrades to the most recent rate limiter crate
and performs explicit chunking of the output so that we
behave more sanely.
Refs: https://github.com/wez/wezterm/issues/65
The defaults are pretty neutral. You can get a little more fancy
with something like this:
```
[colors.tab_bar]
background = "#0b0022"
[colors.tab_bar.active_tab]
bg_color = "#2b2042"
fg_color = "#c0c0c0"
[colors.tab_bar.inactive_tab]
bg_color = "#1b1032"
fg_color = "#808080"
[colors.tab_bar.inactive_tab_hover]
bg_color = "#3b3052"
fg_color = "#909090"
italic = true
```
This is a little ghetto feeling because we're just stealing the top
line from the terminal model, rather than rendering anything
particularly native, but it is relatively quick and easy to do,
and helps improve the feel when using wezterm on a chromebook
inside crostini; in that environment, the system doesn't render
any text in the window titlebars (WTF!?) so it is desirable
to show something to help navigate the UI.
The tab bar is off by default for now; we'll definitely want to
add options to configure at least the colors, and perhaps add
a keybinding to toggle it at runtime.
```
enable_tab_bar = true
```
While adding support for the tab bar, I found a couple of little
bugs relating to computing the number of rows and columns; one
was during resize where we'd use the prior size instead of
the current size. Another was during tab spawning where we'd use
a slightly different calculation to determine the size and end
up raising an error about being confused about the screen size.
The compiler emitted `ud2` right around this code, effectively
breaking wezterm on startup.
In talking this through with @dtolnay, the definition of the
structs in the core_foundation crate makes it undefined behavior
to pass a null pointer to its fields, despite that being a valid
and documented way to use the struct.
This commit works around this by defining our own local versions
of the types and functions with the safe signature.
I'll follow up with the owners of the core_foundation crate
to submit an equivalent patch upstream.
previously we would only ever copy to the clipboard when the selection
was changed.
Now we respect the Copy keypress and have it re-copy the selection
into the clipboard.
previously, if you had defined a list of fonts, we'd show a todo error
and ignore everything but the first entry on linux.
We now parse the list into a set of fontconfig patterns and compose
them together, giving prefernce to the explicitly listed fonts.
(details in the comments in the code).
This allows color emoji to render for user defined fonts without
forcing the user to muck around in fontconfig config.
Added Noto Color Emoji to the fallback; this is used in our
ssh password prompting UI when available.
update to latest macos release (GH actions are removing 10.14).
Explicitly update the toolchain; some instances are still on 1.38
but the current version is 1.39.
