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
