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.
The front-end was treating both \r and \n as Enter and passing
that through to the terminal.
To verify behavior, pay attention to your termios configuration:
```
$ stty -icrnl
$ od -c
<CTRL-J><CTRL-D>
0000000 \n
0000001
$ od -c
<CTRL-M><CTRL-D><Enter>
0000000 \r \n
0000002
```
Closes https://github.com/wez/wezterm/issues/56
Similar to the windows IME support, the placement needs refinement, but
this is sufficient for pinyin input and insertion of emoji via the emoji
palette.
This isn't perfect, but is sufficient to allow using the IME to enter
eg: the heart emoji with cmd.exe.
We have some issues locating and rendering chinese characters that
make it difficult to prove/disprove that the IME is working 100%
because we just can't see the glyphs.
In addition, there appears to be something a bit wonky with conpty and
emoji. If we use eg: `wezterm ssh HOST` to log in to a remote system,
and use the IME to pick eg: the pig face emoji, this renders correctly.
In that scenario we don't use conpty at all.
The IME window is always placed in the top left corner of the window
at the moment, which isn't great, but is better than the system default
which is outside of the window. I need to introduce a way to set the
IME position in the window layer so that the front end gui can set it
to the current cursor position.
Forgetting to update the submodules is a commonly reported build
issue with an obscure error message:
```
CMake Error: The source directory "/home/USER/wezterm/target/debug/build/freetype-430fe24cb64c561c/out/zlib-src/zlib" does not appear to contain CMakeLists.txt.
```
this teaches the build.rs machinery to run the submodule update
if it looks like it is needed.
