The compiler emitted `ud2` right around this code, effectively
breaking wezterm on startup.
In talking this through with @dtolnay, the definition of the
structs in the core_foundation crate makes it undefined behavior
to pass a null pointer to its fields, despite that being a valid
and documented way to use the struct.
This commit works around this by defining our own local versions
of the types and functions with the safe signature.
I'll follow up with the owners of the core_foundation crate
to submit an equivalent patch upstream.
previously we would only ever copy to the clipboard when the selection
was changed.
Now we respect the Copy keypress and have it re-copy the selection
into the clipboard.
previously, if you had defined a list of fonts, we'd show a todo error
and ignore everything but the first entry on linux.
We now parse the list into a set of fontconfig patterns and compose
them together, giving prefernce to the explicitly listed fonts.
(details in the comments in the code).
This allows color emoji to render for user defined fonts without
forcing the user to muck around in fontconfig config.
Added Noto Color Emoji to the fallback; this is used in our
ssh password prompting UI when available.
update to latest macos release (GH actions are removing 10.14).
Explicitly update the toolchain; some instances are still on 1.38
but the current version is 1.39.
This is a bit of a large commit because it needed some plumbing:
* Change mux creation to allow deferring associating any domains,
and to change the default domain later in the lifetime of the
program
* De-bounce the empty mux detection to allow for transient windows
during early startup
* Implement a bridge between the termwiz client Surface and the
frontend gui renderer so that we can render from termwiz to
the gui.
* Adjust the line editor logic so that the highlight_line method
can change the length of the output. This enables replacing
the input text with placeholders so that we can obscure password
input
we were running it immediately which is too soon: the empty
mux check would fire before some of the scheduled jobs would
have run and registered tabs/windows.
on mac the `Delete` key is really `Backspace` and should generate the
`BS` sequence.
`Fn-Delete` is equivalent to the `Delete` key on other keyboards and
should generate the `DEL` sequence.
BS maps to deleteBackward
DEL maps to deleteForward
heads up to @fanzeyi: this partially reverses 8c26b77057
The NSEvent::charactersIgnoringModifiers method ignores modifiers
except for shift, which is unfortunate because it produces eg: `!`
instead of `1`.
This commit adds a mapping from the underlying `keyCode` to the
corresponding letter position.
refs https://github.com/wez/wezterm/issues/34
A number of key bindings that used super on macos are also
aliased with bindings that use CTRL+SHIFT for improved
compat with windows.
On macos, allow sending eg: ALT-F as ALT-F rather than the composed
graphics character (ƒ) that is the default for that combination in
the macos IME.
This is controlled by a new config option which defaults to false
so that we have the expected terminal behavior by default.
This diff adds some plumbing to track the `raw_key` in the KeyEvent;
this is the key prior to composing or eg: mapping dead keys.
With that field in place, we can teach the termwindow layer to attempt
looking up that key mapping from the user defined key bindings.
If we get a match then we can stop further key processing.
Alt-Backspace is the GNUReadline-style shortcut for kill-previous-word.
In wezterm, this currently doesn't work, since this gets trapped by the generic `Backspace` match case.
This diff adds a more specific case for when Backspace is combined with Alt to produce the correct sequence.
This is definitely a hack and there should probably be a more general solution for GNUReadline combinations, but this solves the immediate problem.
I noticed while scrolling `emoji-test.txt` that some of the combined
emoji sequences rendered very poorly. This was due to the unicode
width being reported as up to 4 in some cases.
Digging into it, I discovered that the unicode width crate uses a
standard calculation that doesn't take emoji combination sequences
into account (see https://github.com/unicode-rs/unicode-width/issues/4).
This commit takes a dep on the xi-unicode crate as a lightweight way
to gain access to emoji tables and test whether a given grapheme is
part of a combining sequence of emoji.
Rather than \n and bs these need to be \r and del respectively otherwise
we can end up triggering the wrong ctrl based key mappings in a remote
tmux session.
This was an unintended casualty of the recent gui layer refactoring.
If you press `option-h` macos generates DOT ABOVE which we pass through
to the terminal key processing layer. It sees that ALT is set and emits
an escape byte (to indicate that ALT is set) followed by the UTF-8
sequence for DOT ABOVE. `zsh` gets confused and treats this as
`<ffffffff>` in its line editor.
This diff restricts the emission of the ESC leader to ascii alphanumeric
characters only.
There needs to be a followup diff to allow configuring how we process
these ALT modified characters on macOS because our current behavior
breaks eg: `ALT-1` which is a hotkey that I use in tmux. Granted that
I don't need tmux with end to end wezterm, but it does prevent me from
using that if I wanted to.
I've noticed this off and on for a while, and thought it was something
fishy with my shell dotfiles.
Tracing through I found that the final byte in the "Face with head
bandage" emoji 🤕 U+1F915 was being interpreted as the MW control
code and causing the vt parser to jump out of the OSC state.
The solution for this is to hook up proper UTF-8 processing in the
same way that it is applied in the ground state.
Since we don't have enough bits to introduce new state values (we're
pretty tightly packed in the 16 bits available), I've introduced a
memory of the state to which the utf8 parser needs to return once
a complete sequence is detected.
