Broken config could cause the gui to exit before it would normally
print the config warnings and errors, making it harder to understand
what is going on.
This commit bundles the config error text together with whatever
caused it to error out in the fatal error case.
Now that we have a more regular domain-shaped serial thingy,
refactor the `wezterm serial` command to re-use the common
gui setup and running logic. This removes some FIXMEs from
around the wonky setup of the domain, which is nice.
This commit teaches the config about SerialDomains, and the mux
layer about constructing a SerialDomain, then changes the GUI
layer to use those pieces to set up `wezterm serial`.
A new `serial_ports` config is added, and the GUI layer knows how
to apply it to the set of domains in the mux.
The result of this is that you can now define a domain for each
serial port and spawn a serial connection into a new tab or window
in your running wezterm gui instance.
It's a tremendous PITA for the user to do this at the system level on a
mac, where it is sorely needed. This commit allows raising to a desired
minimum level, but won't decrease from an already larger soft limit.
refs: https://github.com/wez/wezterm/discussions/3353
Three issues:
* The initial connect would leave the dpi assigned to 0, resulting
in incorrect scaling when using imgcat until the window was resized
and the correct dpi was passed up.
* On resize, we'd only compare the row/col count and not notice changes
in pixel dimensions/dpi
* On the server side, when processing a resize and recomputing
the tab size, we would omit the pixel dimensions and leave
the resulting tabs and panes with 0 dimensions, breaking imgcat
because it thought the window was 0x0.
refs: https://github.com/wez/wezterm/issues/3366
This fixes a surprising interaction between copy mode and the
command palette, but is also the root cause of another issue
with CharSelect mode.
refs: https://github.com/wez/wezterm/issues/2947
On macOS prefer CMD, but on other platform prioritize shortcuts
that don't use CMD, as those tend to reserve the CMD based shortcuts
for the system.
Allow specifying how many shortcuts to show if an action has
multiple assignments. The default is 1.
refs: https://github.com/wez/wezterm/issues/3335
added a new `ui_key_cap_rendering` option that accepts the following
values:
```lua
-- Super, Meta, Ctrl, Shift
config.ui_key_cap_rendering = 'UnixLong'
-- Super, M, C, S
config.ui_key_cap_rendering = 'Emacs'
-- Apple macOS style symbols
config.ui_key_cap_rendering = 'AppleSymbols'
-- Win, Alt, Ctrl, Shift
config.ui_key_cap_rendering = 'WindowsLong'
-- Like WindowsLong, but using a logo for the Win key
config.ui_key_cap_rendering = 'WindowsSymbols'
```
refs: https://github.com/wez/wezterm/issues/3335
For items in the main set of key assignments, show the keyboard
shortcut to the right.
Some items have multiple key assignments; we show only the first
one. We'll probably want to be a bit smarter. For instance,
both linux and windows tend to occupy the Windows/Super key
assignments, so we should probably prioritize showing the Ctrl+Shift
variants on those platforms.
refs: https://github.com/wez/wezterm/issues/3335
Given an assignment like this:
```
{
key = "b",
mods = "ALT",
action = wezterm.action.SplitPane {
direction = 'Right',
command = {
label = 'Bash Right',
args = {'/usr/bin/bash' }
}
}
}
```
we should show the label from the command in the palette.
That's what this commit enables.
If there is no label, but the arguments are set, then the
arguments will be shown instead.
refs: #3252
This commit causes the mux to generate a PaneFocused notification
when the active pane is changed.
The mux server will forward that as a unilateral PDU to connected
clients.
The clientpane implementation will handle that by applying the
same state to the local mux.
refs: #2863
* Translate from File to EncodedFile as needed
* Adopt blob leases in the mux server
* Fix an issue where the first image sent by the mux server would
be replaced on the client by its background image, if configured.
Removed the ImageData::id field to resolve this: you should use
the hash field instead to identify and disambiguate images.
Bumped the termwiz API version because this is conceptually
a breaking change to the API
refs: https://github.com/wez/wezterm/issues/3343
This one was a bit weird because something appeared to be a bit
non-deterministic. With this config:
```lua
local wezterm = require 'wezterm'
return {
window_frame = {
border_left_width = '1cell',
border_right_width = '1cell',
border_bottom_height = '0.5cell',
border_top_height = '0.5cell',
border_left_color = '#444',
border_right_color = '#444',
border_bottom_color = '#444',
border_top_color = '#444',
},
window_padding = {
left = '1.5cell',
right = '1.5cell',
top = '0.5cell',
bottom = '0.5cell',
},
}
```
starting wezterm could result in a terminal that reported either 23 or
24 lines. I got 24 when running the build from da7e29df but usually
23 when running a build out of my repo.
Looking closely, the issue is that the initial window size didn't
account for the configured border size, and that we'd subsequently
fix that up when we later do a resize fixup after creating the window.
This commit refactors the window border logic so that it can be
used prior to having fully constructed the terminal window and then
uses that to fixup the initial computed dimensions.
I also noticed with this config that increasing the font size
with CTRL-+ could also result in an inconsistency between the displayed
terminal size and the pty size we set in the kernel: it was missing
the border adjustment as well, so I added it in there.
refs: #3333
The upstream open crate keeps making stuff async/blocking/not-working on
windows, so this is a step towards removing this dependency.
refs: https://github.com/wez/wezterm/issues/3288
The static OnceCell didn't run destructors, so shift to something
where we can explicitly trigger them to run and clean up the
temporary directory area.
This allows the decoder thread to live only long enough
to decode the full set of frames; we can then store the
leases in memory and pull them in only when there is
a cache miss.
refs: https://github.com/wez/wezterm/issues/3263
Adopt the new blob lease layer to storing and referencing
image files.
This reduces the number of open files needed when
images are being displayed in the terminal.
refs: https://github.com/wez/wezterm/issues/3263
Continuing from the previous commit, this shifts:
* In-memory data -> temporary file
* Image decoding -> background thread
The background thread asynchronously decodes frames and
sends them to the render thread via a bounded channel.
While decoding frames, it writes them, uncompressed, to
a scratch file so that when the animation loops, it is
a very cheap operation to rewind and pull that data
from the file, without having to burn CPU to re-decode
the data from the start.
Memory usage is bounded to 4 uncompressed frames while
decoding, then 3 uncompressed frames (triple buffered)
while looping over the rest.
However, disk usage is N uncompressed frames.
refs: https://github.com/wez/wezterm/issues/3263
This makes decoding animation frames a lazy operation, but it
comes at the cost of needing to re-decode the image from scratch
when it loops, because the image crate doesn't provide a way
to rewind its frame iterator.
That initial decode can have a significant time cost; a small
webp file consistently takes 150ms to decode, which is too
much to do inline in the render thread.
Next steps will be to move that cost off the render thread.
In #3260, the candidate animation had a frame delay of 1ms. That is
problematic because there is no hope for wezterm running at 60fps (a
frame delay of ~16ms) to render that without dropping frames.
A consequence of such a short frame delay, coupled with the way that
images are carved up into cells, is that individual cells can easily
become visibled de-synchronized from their neighbors and results in what
looks like mpeg artifacts but are really regions where the cells are a
few frames ahead/behind their neighbors.
The solution is to clamp the frame duration up to match the minimum
displayable frame duration as governed by max_fps.
refs: https://github.com/wez/wezterm/issues/3260
