Following on from 8649056ac0,
this commit should make it harder to make a similar mistake
in the future, by introducing a new TerminalSize struct for
that purpose.
* Allow injecting some initial output to new panes
* Have the update checker set this new-pane-banner to a short
upsell to let the user know there is an update.
* Refactor toast notifications into their own crate
* Have the update checker call a new stub function that triggers
a toast notification with an URL... but it does nothing because
the rust ecosystem doesn't support this on macos yet and I'm
writing this code there
Tidies up the plumbing around pixel dimensions so that ImageData
can be rendered via the termwiztermtab bits.
I put this together to play with sticking the wezterm logo in
the close confirmation dialogs. I didn't end up using that though,
but have preserved the commented code for use in future hacking.
Revise logging so that we use info level for things that we want
to always log, and adjust the logger config to always log info
level messages.
That means shifting some warning level logs down lower to debug level so
that they aren't noisy.
closes: https://github.com/wez/wezterm/issues/388
in ab342d9c46 I started to rearrange how
the output processing thread works. It wasn't quite right, so this
commit tidies things up.
The main change here is that there is now back-pressure from the output
parser on the reader; if it is taking a while to parse the output then
we don't buffer up so much input.
This makes operations like `find /` followed immediately by `CTRL-C`
more responsive.
With this change, I don't feel that the
`ratelimit_output_bytes_per_second` option is needed any more, so it
has been removed.
This removes the ratelimiter from the mux pty output reader.
Instead, we now have two reader threads:
* One to perform blocking reads from the pty output and send them
to the other thread
* The other thread waits for data from the first, then tries to find
a newline character so that it can send 1+ lines of data to the
terminal parser. If it doesn't find any lines, it waits ~50ms for
additional data from the first thread to bundle together eg:
really long lines, or image protocol data. It will keep doing this
until no more data arrives within 50ms or until it finds a newline.
Once no more data arrives within 50ms, it sends whatever it has
accumulated and then blocks waiting for the next chunk
I tried a quick ctrl-c test with this; running `find /` and seeing
how easily interruptible it is, and it seems OK on my M1 mac.
I don't think we need the output rate limiter any more, but I'll
try this out on my bigger linux machine as well to see if that
feels as good.
With this change, `cat test-data/emoji-test.txt` no longer has wonky
spacing when it gets to the England flag at the bottom.
refs: https://github.com/wez/wezterm/issues/339
This is one of those massive time sinks that I almost regret...
As part of recent changes to dust-off the allsorts shaper, I noticed
that the harfbuzz shaper wasn't shaping as well as the allsorts one.
This commit:
* Adds emoji-test.txt, a text file you can `cat` to see how well
the emoji are shaped and rendered.
* Fixes (or at least, improves) the column width calculation for
combining sequences such as "deaf man" which was previously calculated
at 3 cells in width when it should have just been 2 cells wide, which
resulted in a weird "prismatic" effect during rendering where the
glyph would be rendered with an extra RHS portion of the glyph across
3 cells.
* Improved/simplified the clustering logic used to compute fallbacks.
Previously we could end up with some wonky/disjoint sequence of
undefined glyphs which wouldn't be successfully resolved from a
fallback font. We now make a better effort to consolidate runs of
undefined glyphs for fallback.
* For sequences such as "woman with veil: dark skin tone" that occupy a
single cell, the shaper may return 3 clusters with 3 glyphs in the
case that the font doesn't fully support this grapheme. At render
time we'd just take the last glyph from that sequence and render it,
resulting in eg: a female symbol in this particular case. It is
generally a bit more useful to show the first glyph in the sequence
(eg: person with veil) rather than the gender or skin tone, so the
renderer now checks for this kind of overlapping sequence and renders
only the first glyph from the sequence.
This causes `tmux -CC attach` to enter control mode and patch
into the terminal, printing out parsed event messages.
refs: https://github.com/wez/wezterm/issues/336
Adds some supporting methods for computing the `SemanticZone`s
in the display and a key assignment that allows scrolling the
viewport to jump to the next/prev Prompt zone.
This commit moves a bunch of stuff around such that `wezterm` is now a
lighter-weight executable that knows how to spawn the gui, talk to
the mux or emit some escape sequences for imgcat.
The gui portion has been moved into `wezterm-gui`, a separate executable
that doesn't know about the CLI or imgcat functionality.
Importantly, `wezterm.exe` is no longer a window subsystem executable
on windows, which makes interactions such as `wezterm -h` feel more
natural when spawned from `cmd`, and should allow
`type foo.png | wezterm imgcat` to work as expected.
That said, I've only tested this on linux so far, and there's a good
chance that something mac or windows specific is broken by this
change and will need fixing up.
refs: #301
025732d00f introduced deferred
window creation; the creation would get scheduled into the
spawn queue and then get run again a few milliseconds later
on the main thread.
For reasons that I don't understand, returning to the scheduler
loop to flush or otherwise process messages causes a wayland
protocol error.
Adjusting the notify routine to dispatch immediately if we're
already on the mux thread seems to resolve this.
While looking at this, I cleaned up a destruction order issue
with the opengl state that was then causing a segfault on shutdown.
I also removed a bit of dead paint related code that doesn't
appear to be needed any more.
refs: #293
This commit adds very basic first passes at representing the Pane
and GuiWindow types in lua script.
The `open-uri` event from 9397f2a2db
has been redefined to receive `(window, pane, uri)` parameters
instead of its prior very basic `uri` parameter.
A new key assignment `wezterm.action{EmitEvent="event-name"}` is
now available that allows a key binding assignment to emit an arbitrary
event, which in turn allows for triggering an arbitrary lua callback
in response to a key or mouse click.
`EmitEvent` passes the `(window, pane)` from the triggering window and
pane as parameters.
Here's a brief example:
```lua
local wezterm = require 'wezterm';
wezterm.on("my-thingy", function(window, pane)
local dims = pane:get_dimensions();
wezterm.log_error("did my thingy with window " .. window:window_id() ..
" pane " .. pane:pane_id() .. " " .. dims.cols .. "x" .. dims.viewport_rows);
window:perform_action("IncreaseFontSize", pane);
end)
return {
keys = {
{key="E", mods="CTRL", action=wezterm.action{EmitEvent="my-thingy"}},
}
}
```
refs: #223
refs: #225
Rather than having each call site add a window to the mux and then
call the front end to spawn a window, make the mux emit a signal
advising of a window spawn, and have the front end subscribe to
that signal.
