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
I spent a few hours in heap profilers. What I found was:
* Inefficient use of heap when building up runs of
`Action::Print(char)`.
-> Solve by adding `Action::PrintString(String)`
and accumulating utf8 bytes rather than u32 codepoints.
* Inefficient use of heap when building Quad buffers: the default
exponential growth of `Vec` tended to waste 40%-75% of the allocated
capacity, and since we could keep ~1024 of these in cache, there's
a lot of potential for waste.
-> Solve by bounding the growth to 64 at a time. This has similar
characteristics to exponential growth at the default 80x24 terminal
size. May need to add a config option for this step size for users
with very large terminals.
* Lazy eviction from the LFU caches. The underlying cache advisor is
somewhat probabilistic and has a minimum cache size of 256, making
it difficult to maintain low heap utilization.
-> Solve by replacing it with a very simple LFU algorithm. It doesn't
seem to hurt much at the default terminal size with the default
cache sizes. If we make the cache sizes smaller, its overhead is
reduced.
Some further experimentation is needed to adjust defaults, but this
should help reduce heap usage.
refs: https://github.com/wez/wezterm/issues/2626
It can be helpful for debugging purposes.
The socket can be discovered by setting:
WEZTERM_LOG=wezterm_mux_server_impl::local=trace,info
to get it to log a line like:
```
setting up /Users/wez/.local/share/wezterm/gui-sock-38183
```
Then it can be helpful to do:
```
WEZTERM_UNIX_SOCKET=/Users/wez/.local/share/wezterm/gui-sock-38183 wezterm cli list
```
to see what is in the gui's mux model.
refs: https://github.com/wez/wezterm/issues/2616
When using `key_map_preference="Mapped"`, `ctrl-shift-1` is actually
`ctrl-shift-!` in a US layout.
This commit adds the us-layout mapping for shifted number keys to
allow that to work, but it is worth calling out that this will only
be meaningful in layouts that have the same US mapping for the number
keys.
refs: https://github.com/wez/wezterm/issues/2623
I've expanded the number of bits from 16->32 without impacting
the overall struct sizes and reserved 2 bits for super/subscript.
I refer to these as vertical alignment properties for conceptual
consistency with css.
SGR 73, 74, 75 are used to set super, sub and normal vertical alignment.
These are compatible with mintty.
However, mintty just added support for setting both attributes to render in
small caps in 06ac446049
(https://github.com/mintty/mintty/issues/1171)
I was going to upgrade to the unicode 15 font, but in testing this I
decided that the logic is slightly complex and the glyphs are often
difficult to see at most terminal font sizes, which generates questions
from users, so just fall back to notdef.
The clustered line storage impl of get_cell() is O(column-index)
as cells have to be iterated in order.
The render pass was calling it 3 times to resolve information
about the cursor; reduce that to just once.
It was also calling it once per cell to determine whether the
cell needed to be replaced with a custom glyph if custom block
glyphs were enabled, making it accidentally quadratic!
While it wasn't especially expensive, it did show up in profiling,
so this commit removes that call: we can cache the block glyph
key in the shaper info which is a better place for it anyway,
so that's what we do.
Similarly, there was some extraneous work to call get_cell
when computing some shaper info; remove that too!
That one might be slightly contentious: the is-followed-by-space
logic used to check the successor cell by index to see if it
was a space, but now looks at the successor shaped glyph to see
if it was a space. That might actually be a better choice, but
it may have some ripple effects.
According to its benchmarks, it's almost 2x faster than
unicode_segmentation. It doesn't appear to make a visible
difference to `time cat bigfile`, but I'll take anything
that gives more headroom for such little effort of switching.
This is a weird attribute TBH.
xterm seems to replace the cells with spaces: copying and pasting
results in spaces.
Kitty ignores it.
VTE doesn't render it but allows copying and pasting.
The latter is now also the behavior in wezterm.
This provides a means for more easily extending the default key
tables without forcing the user to recreate the entire config
for themselves.
wezterm.gui.default_keys is also added by this, but it is likely
not as useful.
There were two problems:
* We weren't correctly invalidating when the hover state changed
(a recent regression caused by recent caching changes)
* We'd underline every link with the same destination on hover,
not just the one under the mouse (longstanding wart)
Recent changes allow the application layer to reference the underlying
Lines directly, so we can restore the original and expected
only-highlight-under-the-mouse by switching to those newer APIs.
Adjust the cache values so that we know to also verify the current
highlight and invalidate.
I was a little surprised to see that this also works with mux client
panes: I was expecting to need to do some follow up on those because
they return copies of Line rather than references to them. That happens
to work because the mux client updates the hyperlinks at the time where
it inserts into its cache. The effect of that is that lines in mux
client panes won't update to new hyperlink rules if they were received
prior to a change in the config.
refs: https://github.com/wez/wezterm/issues/2496
This makes the search feel more responsive.
We search from bottom to top so that we show the more recent results
first, but for the sake of efficiency when accumulating result chunks
we need to reverse the order of the results vec from how it was
previously.
Each result chunk is loosely ordered from top to bottom, so we sort
it and reverse it: results[0] is the bottom-most result.
New rows are accumulated on the end of the result array; this is
not only more efficient, but it preverses the match result number
ordering.
The next/prior functions need to be swapped to account for this change
in result order.
refs: https://github.com/wez/wezterm/issues/1209
It was set to the first non-tab bar pixel y coordinate rather than
the line y pixel coordinate.
Move the calculation up!
refs: https://github.com/wez/wezterm/issues/2483
There are caveats to determining this, but when we think
password entry is enabled, switch the cursor to the font-awesome
lock glyph instead of the normal cursor sprite.
fa_lock is used because it is monochrome and can thus be tinted
to the configured cursor color, and it respects blinking/easing.
refs: https://github.com/wez/wezterm/issues/2460
