fix: option as meta when control and command are pressed #1096
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The proposed change is to address issue #1095
It treats the Option key as Meta (or Alt) if either Command, or Control is also pressed. It also treats the Option key as Meta if the other pressed key is a special key (i.e. arrow keys).
In any other scenarios, the Option key behaviour is unchanged.
This allows for users of non-qwerty layouts (such as the azerty layout) to map Control+Alt sequences, while retaining the ability to insert characters that require the use of the option key (including, but not limited to
{
and[
, in the case of the azerty layout).This replicates the behaviour observed in common terminal emulators such as Kitty, WezTerm and Alacritty.
The "option as alt" settings are still honored and no change of behaviour is to be expected by users of these options.
I am not so happy with the
flags.contains("C-")
check inKeyUtils.isControlCode(key:, flags:)
function, I’d be happy to have suggestions on how to improve that.