It's not really moved, but rather duplicated there; we still have
fallback logic in terminalstate.rs that processes the equivalent
action, but adding the logic to the gui layer means that we can
process it in terms of the Tab and Renderable interfaces.
refs: https://github.com/wez/wezterm/issues/106
On x11 we'd get just a single line per scroll wheel tick.
Contrast with Wayland where we get multiple.
This config change makes us feel more snappy by default on X11.
I'd like to make this configurable using the live configuration
infra, but we don't currently have a way for this crate to see
that config, so this just changes the default to be "better".
refs: https://github.com/wez/wezterm/issues/92
When the scrollbar is disabled we still create a quad for it, and that
quad stretches to the window height. It is left with undefined texture
and could be either partially or totally transparent and lead to weird
effects like it appearing as though the titlebar was too wide for the
window, or by dimming the RHS of the window when toggling the scroll
bar on and off a few times.
This commit ensures that we set a well defined size and color when
the scroll bar is disabled, and seems to improve things for me.
Refs: https://github.com/wez/wezterm/issues/103
This commit adds the ability to change the relative or absolute
position of a tab within its containing window through the
use of a key assignment.
We include a default assignment of CTRL+SHIFT+PageUp for moving
left and CTRL+SHIFT+PageDown for moving right.
Closes: https://github.com/wez/wezterm/issues/84
If the cells refer to the same object instance (rather than equivalent
instances), then we treat them as part of the same highlight.
Refs: https://github.com/wez/wezterm/issues/94
Now that we can track focus changes, we can eliminate an annoyance:
clicking in the window to focus it would cause a click event to
be passed to the terminal and clear the selection.
This commit will swallow button events that occur within 200ms
of the focus being gained by the window.
This reverts commit bfa8d0c207,
which proved not to be needed because it was already covered
by the `KeyboardEvent::Enter` and `KeyboardEvent::Leave` handling.
Previously we would try to pass through the Backspace and Delete
code points without interference, but that behavior wasn't quite
right.
With this commit our behavior is now:
- At the window layer: Classify a `Backspace` key press as logically
`BS` and a `Delete` key press as logically `DEL` unless the
`swap_backspace_and_delete` is true (macOS is true by default), in
which case `Backspace` is mapped to `Delete` and vice versa.
- At the terminal input layer: A `Backspace` input from the Window sends
the `DEL` sequence to the pty as that matches the default `VERASE` stty
configuration. A `Delete` input from the Window emits `\033[3~`,
which matches up to the `TERMINFO` for `xterm-256color` which we
claim to be compatible with, and is our default `$TERM` value.
The net result of this is that `Backspace` will now start to emit `^?`
which should match folks stty verase. Heads up to @fanzeyi!
I've tested this only on a linux system so far and will follow up on
a macOS system a little later today.
Refs: https://github.com/wez/wezterm/issues/88
Refs: https://github.com/wez/wezterm/issues/63
