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
This sequence forms a grapheme with cell_width=2, but harfbuzz returns
it as two distinct clusters, causing our prior logic to shape them
independently from different fonts, but our logic for assessing width
would resolve them both to the same cell and double-count their width,
leading to issues with the rendered result.
This commit revises our clustering logic to add a pass that compares
the harfbuzz cluster positions with the cell-based positions from
the presentation_width that may have been provided. We use the starting
cell positions from that to order and de-dup so that clusters aren't
split in the wrong place.
refs: https://github.com/wez/wezterm/issues/2572
We weren't including the invisible space cells into the model
as part of building up the logical line, resulting in the logical
line being shorter than it should have been.
That resulted in some of the components of the double wide cells
not being rendered in the correct place.
refs: https://github.com/wez/wezterm/issues/2571
refs: https://github.com/wez/wezterm/issues/2568
We weren't matching the domain id when resolving the remote->local pane
mapping, which meant that having 2 or more mux client domains active
would lead to associating eg: remote pane id 1 with whichever local
pane was associated with any remote pane id 1 *first*.
This commit requires that both the domain id and the remote pane id
match.
refs: https://github.com/wez/wezterm/issues/2616
When closing the all mux tabs in a window, the remote will close
the window. If the local has a mixture of local and remote tabs
then subsequent attempts to spawn a tab in that window would
fail due to reusing the stale remote window id.
This commit purges the local/remote mappings that are (probably)
dead when the remote indicates that a pane has been removed.
The mapping should be re-established as needed later on.
refs: https://github.com/wez/wezterm/issues/2614
`iter_panes` returns the renderable set of panes, but most functions
in the mux want to operate on the full set of panes.
Notably, when closing a tab, we were not killing panes other than
the zoomed pane, which caused wezterm to linger in the background.
refs: https://github.com/wez/wezterm/issues/2548
I'd like to push that into the status bar, so nudge people towards
that in the docs for this.
There is a config option to restore it. I'd like to ultimately
remove that though.
refs: https://github.com/wez/wezterm/discussions/2542
https://github.com/wez/wezterm/pull/2435 proposed including
CTRL-modified keys, but I think that the state of the code now means
that we can simplify that area and adjust it so that we will default to
routing keys to the IME, but excluding them based on the
`send_composed_key_when_(left|right)_alt_is_pressed` configuration.
I've only very lightly tested this, but it seems ok with roman text and
me punching in random pinyin and then using CTRL-H or CTRL-M to delete
or enter.
refs: https://github.com/wez/wezterm/pull/2435
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.
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
