The client machinery would try to spawn an async attempt at
detaching the unixdomain from the mux on shutdown, but since
we're in the middle of tearing down the scoped executor,
we could sometimes panic.
The client we have in this situation isn't actually associated
with a domain, so we don't need to detach in that situation.
Formalize that by making it an Option, and address the
fanout.
Using the new publish/discovery stuff from the past couple of commits,
if we can find a matching socket path for a running gui, and the
configuration is likely a match, then use the mux protocol to talk
to the already running gui and ask it to spawn the equivalent program
into the same process.
refs: https://github.com/wez/wezterm/discussions/1486
We need 100% of the info for it to work correctly, so this commit:
* Exposes the keyboard encoding mode via the Pane trait
* Adds the scan code to the RawKeyEvent
* Has the GUI perform the encoding if the keyboard is set that way
* Removes the basic encoder from termwiz in favor of the gui level one
The net result is that we bypass the Pane::key_up/Pane::key_down methods
in almost all cases when the encoding mode is set to win32-input-mode.
There is now a config option: allow_win32_input_mode that can be
used to prevent using this mode.
refs: #1509
When spawned with no WEZTERM_UNIX_SOCKET environment set,
we now prefer to resolve the gui instance, falling back to
the mux if it doesn't look like the gui is running.
`wezterm cli --prefer-mux` will use the original behavior of
trying to resolve the path from the unix domain in the config.
This commit causes the terminal to emit win32-input-mode encoded key up
and down events for a limited subset of keys When win32-input-mode is
enabled.
We limit them to keys where we know the VK key code equivalent,
and where those keys are either not representable (eg: modifier
only key events), or may generate ambiguous output (eg: CTRL-SPACE
in different keyboard layouts).
However, in my experiments, modifier only key presses confuse powershell
and cause it to emit `@`, so I've disabled that in the code for now.
refs: https://github.com/wez/wezterm/issues/318
refs: https://github.com/wez/wezterm/issues/1509
refs: https://github.com/wez/wezterm/issues/1510
Nothing generates them right now, and the mux client has no
way to represent them on the wire.
I'm considering constraining them to just win32 for now.
refs: https://github.com/wez/wezterm/issues/1509
This is a baby step that formalizes the different encoding schemes into
an enum, and hooks up the decset sequence for win32-input-mode.
It doesn't change any of the actual encoding at this time.
refs: #1509
It was showing the whole text for the cluster for each shaped
glyph.
Fix it up to map back to the corresponding cell range and
extract the text from the line.
Include the x_advance metric in the output while we're in
there.
refs: https://github.com/wez/wezterm/issues/1333
When rendering the IME composing text, I noticed that for the Korean
input sequence: shift+'ㅅ' followed by 'ㅏ' we'd render the 'ㅆ' (the
shifted first character) in black and the composing 'ㅏ' in white
against the cursor color, and that was very difficult to read,
especially at the default font size.
To resolve this, this commit:
* Forces clustering to break around the cursor boundary, so that
we treat the cursor position as its own separately styled cluster
* Adjusts cursor/bg rendering so that we always consider the start of
the cluster for the colors of that run. We are guaranteed that a
ligatured sequence will fit in the background area anyway.
This has the effect of "breaking" programming ligatures such as '->'
when cursoring through them, and decomposing them into their individual
'-' and '>' glyphs, which is a reasonable price to pay for being able
to see things better on screen.
refs: https://github.com/wez/wezterm/issues/1504
refs: https://github.com/wez/wezterm/issues/478
