I don't have a great way to test this on those platforms,
so other than compiling and running and verifying that things
work normally, I'm not sure if this is sufficient!
This commit allows distinguishing between left and right alt
modifiers at the window layer. So far only macos provides
this additional information.
Expand the logic that decides whether Alt should emit the
composed key or act as the raw key with the Alt modifier flag
set so that we can set that behavior separately for the left
and right modifiers on systems that support it, and use the
existing config for systems that don't support it.
The default settings for these flags is that Left Alt will
send the uncomposed key + Alt modifier while the Right Alt
will behave more like AltGr (which is typically on the RHS
of the keyboard) and send the composed key.
This gives more flexibility by default and hopefully matches
expectations a bit better.
refs: https://github.com/wez/wezterm/issues/216
Some applications want to control the cursor visibility, without affecting
cursor shape. Provide the `CursorVisibility` change type for this purpose.
Use this when dropping `UnixTerminal` to ensure the cursor is visible
without affecting the user's cursor shape.
Since most users are unlikely to have built from source, adjust
the script so that it will find their installed wezterm.
Adjust the issue template to reference the wt-record script.
This was originally intended to be swept in and dealt with as part of
adopting CSI-u (refs: https://github.com/wez/wezterm/issues/63) but the
default shift-space mapping is super irritating in vim (refs:
https://github.com/wez/wezterm/issues/126) so it got partially walked
back, but as a consequence we accidentally dropped the modifiers from
those keys (refs: https://github.com/wez/wezterm/issues/213 refs:
https://github.com/wez/wezterm/issues/214).
This commit restores the modifiers for that case.
In addition, since we now have a way to plumb configuration directly
into the term crate, this adds a config option to enable CSI-u for those
that want to use it.
Previously, we'd require boxing the entire DCS representation
in the escape sequence parser. This was due to some clippy
advice that made sense at the time, but now that I'm looking
at more things using DCS it seems wasteful to Box each byte of
the dcs sequence. This commit shifts the box to the heavier
weight portion: the DCS hook/entry representation.
When processing `\033[?1002;1003;1005;1006h`, when we encountered
`1005` we would skip 1006. This was because we hit the unspecified
enum case for 1005 (we have no enum variant for that mode) and that
code path didn't properly advance only by a single position.
This commit fixes that.
refs: https://github.com/wez/wezterm/issues/211#issuecomment-641302077
This corrects an issue where the mode byte of the DCS sequence was
discarded from the DcsHook, making it impossible to know what sequence
is being activated.
So far this hasn't come up as these sequences are relatively rare,
but in looking at sixel parsing I noticed the error.
If the image is smaller than the cell size we could end up
rounding that dimension to zero and ultimately not render
the texture to the cell.
This commit adjusts the math to round up, which yields
better results for the test in refs: https://github.com/wez/wezterm/issues/211
