This allows removing a bunch of unwrap/expect calls.
However, my primary motive was to replace the cases where we used
Mux::get() == None to indicate that we were not on the main thread.
A separate API has been added to test for that explicitly rather than
implicitly.
Implement an app delegate to receive a callback when the system
requests that we open `.command` files, and then ask the mux
layer to spawn a window for it and execute it via the shell.
Also allow handling `.sh`, `.zsh`, `.bash`, `.fish` and `.tool`,
per kitty.
refs: https://github.com/wez/wezterm/issues/2741
refs: https://github.com/wez/wezterm/issues/2871
Using the new abstractions, we can call into webgpu code now.
It doesn't do anything useful, and in fact crashes because
the mapping of the quads is doing the wrong thing.
Will fix in the next commit.
The recent changes to clustering make this more likely to happen.
This doesn't handle overflow resulting from changing styles in the tab
title, but those are less common.
refs: https://github.com/wez/wezterm/issues/2560
Since we're no longer tied to contiguous Vertex slices, we can
record the Quad data used for HeapQuadAllocator in a smaller structure,
so that's what this does.
It reduces the per-Quad storage from 272 bytes down to 84 bytes,
which helps with overall memory usage: the default cache size is 1024
lines worth of quads, so this can add up to multiple MB of RAM.
refs: https://github.com/wez/wezterm/issues/2626
This reduces peak heap usage by several MB by making better use
of allocated memory--no wasted overhead in the Vec capacity.
refs: https://github.com/wez/wezterm/issues/2626
When a line is rapidly updated with only some of the cells being
actually changed (eg: progress counter or other status being frequently
updated), it is desirable to avoid paying the cost of shaping the entire
line.
When bidi is not enabled we can assume that it is safe to break clusters
on whitespace boundaries. Doing so allows each of those whitespace
separated words to be shaped and potentially cached independently,
which reduces the amount of CPU time spent for the whole line.
This commit just adjusts the clustering, which reduces the CPU
utilization a bit.
refs: https://github.com/wez/wezterm/issues/2701
Do it "more properly": use intrusive list linkage to manage three
indices:
* hash lookup
* recency
* frequency
eviction is frequency based, but in order to avoid things that were
super hot in the past and that are no longer hot clogging up the cache,
eviction will incrementally age out least recently used entries that
haven't been active in the span of some number of get/put operations.
Aging scales down the frequency value to reduce its strength, so an aged
item isn't necessarily immediately a candidate for removal, it just
makes it more likely to be picked up by the frequency based removal as
it goes unused for an extended period.
Right now wezterm already allows to pass a cmdline to execute (instead
of the shell) by calling "wezterm start" with trailing arguments, e.g.
wezterm start -- bash
However, most other terminals implement this via a "-e" option. This
seems to be adopted widely in the wild, such that some third-party
frameworks just blindly expect the user's terminal to use the "-e"
option for this.
One such notable framework is kio from KDE Plasma, that calls the user's
terminal in that way when launching a desktop file that uses
Terminal=true. [1]
To solve this problem, we add a compatibility layer by adding a dummy
"-e" option. This will then consume the "-e" leaving the remaining
arguments as trailing arguments, which will later be consumed by our
existing implementation in the "prog" option.
Given that clap does not really support multiple arguments writing to
the same destination [2], this seems like the most sane implementation,
even if it is a hack.
It seems to work reliable, even for edge cases where we pass wezterm
options as trailing arguments, e.g. the following will just work and do
the expected outcome (and will **not** parse "--position" as a wezterm
argument):
wezterm start -e echo --position 10,10
Fixes#2622
[1] https://bugs.kde.org/show_bug.cgi?id=459616
[2] https://github.com/clap-rs/clap/issues/3146
I can't think of a good reason for this being here. I think I
may have been lazy about resolving the lifetime annotations
and just stuck in an extra buffer while building the original
version of this logic, and then forgot about it.
This commit resolves the lifetime annotations and directly
references the passed in buffer.
refs: https://github.com/wez/wezterm/issues/2626
