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
We need to build in release mode so targets are cacheable.
GH has a limit of 400MB per cache blob and we're at 750MB with
the debug build. Slim it down a bit.
The cache wants to hash the Cargo.lock file so I've removed that
from the ignore file and added it to the repo. This might cause
an error for users checking out the repo after this change is
pushed; removing the local Cargo.lock should resolve that.
The cursor should only start blinking when its been sitting in once place;
a moving cursor should always be visible. Rather than making the cursor blink
relative to the creation time of the window, track its position, and use the
last time it moved as the blinking timebase.
Fixes https://github.com/wez/wezterm/issues/83
This is a bit of a speculative change to see if it helps with
refs: https://github.com/wez/wezterm/issues/82
I have sometimes seen my scrollbar have a color that I didn't
choose and ISTR having some issues in the past when updating
the quads if I didn't set all of the fields of the vertex
to a better defined value.
These are used in the default Fedora 31 bash profile, so it seems
worth handling even if they are a bit amgiguously defined.
Closes: https://github.com/wez/wezterm/issues/86
A while back I moved the clipboard related processing mostly out
of the term processing code, but since I mostly use the keyboard
for pasting, I'd overlooked the middle mouse button paste flow.
This is problematic because fetching the clipboard requires a
degree of inter process communication and needs the event loop
to be pumped. Since the terminal callbacks are dispatched from
an event loop callback, attempting to block on the clipboard
future causes a deadlock.
This commit resolves that issue by anticipating that we'll need
the clipboard contents for the majority of middle mouse button
clicks and scheduling a fetch and cache ahead of passing that
event down to the terminal layer.
Why don't we simply use the same technique as the Paste key
assignment? If the terminal is currently using SGR mouse
tracking mode then the application on the other end of the
pty will want the raw button press. Our layering doesn't
allow for passing up the concept of whether a middle button
does paste or sends the raw event.
tricksy!
Refs: https://github.com/wez/wezterm/issues/87
