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
This replicates `last-window` in tmux. To pull this off, I
deliberately store the last tab whenever I'm activating a new one or
spawning a new one. I had to do this explicitly rather than hooking
set_active, because we end up setting the active tab briefly for some
common operations like moving a tab.
There are a few notable changes as a result:
* A number of `.ssh/config` options are now respected; host matching
and aliasing and identity file are the main things
* The authentication prompt is inline in the window, rather than
popping up a separate authentication window
Refs: https://github.com/wez/wezterm/issues/457
These now operate in terms of logical lines so they deal with
lines that have wrapped outside the viewport better than in
previous releases.
closes: https://github.com/wez/wezterm/issues/408
The wincng based build doesn't recognize newer keys which makes it
impossible to connect to a reasonably up to date Fedora installation.
This commit points to my branch of ssh2-rs that has some changes to
build ssh2 against the vendored openssl that is already part of
the dependency graph for wezterm.
refs: https://github.com/wez/wezterm/issues/507
I don't understand how fish ends up blocking forever in the related
issue, but it shouldn't block us too! The price of this situation
is likely a lingering zombie child process but that seems fine.
refs: https://github.com/wez/wezterm/issues/558
I've had a few people comment that the screen repaints stutter
more since the most recent release.
One of the main changes in that area was to increase throughput
for timg case, where a lot of data was being pumped through.
I think that, ironically, the decreased latency results in more
frequent repaints where not all of the updated screen is visible
in a full screen redraw, so it appears more janky.
This commit introduces a small 1ms delay to see if additional
output is forthcoming when parsing the data. It will keep
delaying and accumulating until there's at least one parsed
output action to process, so there is a small constant latency
overhead added to a single character output (thread context
switch + 1ms delay).
This small delay is counter-balanced with raising the priority
of dispatching the render actions; previously we'd spawn them
at lower-than-input priority. With the batching potential,
I think spawning them at the same priority is OK; the main
reason for the lower priority was to ensure timely ctrl-c
processing when a lot of output is being dumped to the terminal.
It's hard for me to gauge whether this fixes the reported issue,
as I've been unable to reproduce it for myself.
refs: https://github.com/wez/wezterm/issues/559
refs: https://github.com/wez/wezterm/issues/546
I'm not convinced that this is 100% good, but @fanzeyi reported
some latency when using tmux to mirror two sessions. The session
that was accepting interactive input responded quickly, but the
mirroring session was laggy.
This change connects the mux pane output event to window invalidation,
which should cause repaints to happen more often.
I couldn't reproduce the scenario above on my M1 mac, but that may
just be because M1 has dark magicks.
I've been meaning to do this for a while; this commit moves
the escape sequence parsing into the thread that reads the
pty output which achieves two goals:
* Large escape sequences (eg: image protocols) that span multiple
4k buffers can be processed without ping-ponging between the
reader thread and the main gui thread
* That parsing can happen in the reader thread, keeping the gui
thread more responsive.
These changes free up the CPU during intensive operations such
as timg video playback.
This is a slight layering violation, in that this processing
really belongs to local pane (or any pane that embeds Terminal),
rather than generically at the Mux layer, but it's not any
worse a violation than `advance_bytes` already was.
refs: https://github.com/wez/wezterm/issues/537
In a couple of quick tests, this doesn't seem to break cat'ing
the emoji test data so it seems like it isn't needed anymore.
In addition, it removes a bottleneck from processing image
streams produced by timg, which tend to be very large with
new newlines.
With this change, I'm able to view a 25fps source video at
about 60fps.
refs: https://github.com/wez/wezterm/issues/537
This is defined as a trait method on Pane (default: false), and has the
obvious transitive equivalent methods in Tab and Window (eg: if all
contained items are `can_close_without_prompting`, then that container
is also `can_close_without_prompting`).
The intent is to avoid bothering the user to confirm closing a window
when the content is not stateful and doesn't warrant it.
For example: the window that is displayed in the event of a
configuration error really shouldn't prompt to the user to confirm
closing it.
All termwiztermtab panes are `can_close_without_prompting==true`
to effect this policy.
In the future, we could teach LocalPane to lookup the session leader
process against a list of "uninteresting" or "stateless" processes
and return an appropriate result (as suggested in
https://github.com/wez/wezterm/issues/280). That functionality
is NOT part of this commit.
`exit_behavior = "Hold"` will keep the pane alive until explicitly
closed. More details in the docs that are part of this commit.
refs: https://github.com/wez/wezterm/issues/499
* Add ClearBuffer action
Clears all lines, both visible and those scrolled off the top of the viewport, making the prompt line the new first line and resetting the scrollbar thumb to the full height of the window.
This is the behavior that Hyper / xterm has for clearing the terminal.
* Combine ClearBuffer into ClearScrollback as enum with associated erase mode
Makes it easier to manage the different options of clearing the terminal.
This appears to have been broken since the introduction of mouse
assignments :-/
This commit adds Pane::is_alt_screen_active so that the gui layer
can tell whether the alt screen is active, and allow passing down
the event.
refs: #429
It's been replaced with an opaque termwiz error type instead.
This is a bit of a more conservative approach than that in (refs: #407)
and has less of an impact on the surrounding code, which appeals to
me from a maintenance perspective.
refs: #406
refs: #407
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.
