Remove a normalizing function that made assumptions based on the
keycaps that did not hold up when selecting Dvorak as an input
source. For example "CTRL-C" where `C` is the key with the C keycap
would send `CTRL-C` even when Dvorak was selected; it should send CTRL-J
in that layout.
I think with the other normalization that happens in the termwindow
layer we don't need this function any more.
We now display a list of tabs and allow selecting them with either
the up/down arrows or the k/j keys. Enter activates the selected
tab, Escape cancels the overlay.
An overlay is a little termwiz app that can be overlaid over the
content of a gui tab.
The intent is for these to provide the mechanism for meta operations;
listing all tabs in a long-form list and switching between them,
dropping into configuration or error log review and so on.
We now show a little status window when we're making a connection
for a remote mux domain.
This should make things feel slightly nicer if there is a connectivity
problem.
refs: https://github.com/wez/wezterm/issues/127
Rather than just a single attempt at each mechanism, let's allow up
to 3 loops, each time trying all supported mechanisms. This helps
for the case where the user makes a typo with their password, and
should also help for more complicated auth setups where succeeding
with one mechanism may not be sufficient.
While testing this out I noticed that were deferring closing the
OS level window until after the entire auth attempt, so I added
some logic to proactively close the prompt windows. In the longer
term I'd like all related prompts to render in the same window
for improved cognotive continuity.
This matches cmd.exe and other programs (notepad, office, etc) behavior:
First click selects "start", then Shift+click selects "end". They form
a range.
This is particularly useful to select a large range of text, since the
user can release the left button, then operate on the scroll bar without
worrying about messing up text selection.
It gets a bit more complicated with the POSIX "mouse grabbed" situation.
When the mouse is grabbed, it's usually a full-screen ncurses-like
application. Selection mostly likely only makes sense within a single
screen. So Shift + LeftClick just works as starting a selection in this
case (otherwise it'll be hard to clear a selection).
The default values are 3 lines. With this change, scrolling speed now seems
similar to other programs like cmd.exe. Before this change it feels too slow.
I noticed my trackpoint or touchpad reports a lot of < 120 (WHEEL_DELTA) events.
They shouldn't be ignored.
Also https://docs.microsoft.com/en-us/windows/win32/inputdev/wm-mousewheel says:
> The wheel rotation will be a multiple of WHEEL_DELTA, which is set at 120.
> This is the threshold for action to be taken, and one such action (for
> example, scrolling one increment) should occur for each delta.
>
> The delta was set to 120 to allow Microsoft or other vendors to build
> finer-resolution wheels (a freely-rotating wheel with no notches) to send
> more messages per rotation, but with a smaller value in each message. To use
> this feature, you can either add the incoming delta values until WHEEL_DELTA
> is reached (so for a delta-rotation you get the same response), or scroll
> partial lines in response to the more frequent messages. You can also choose
> your scroll granularity and accumulate deltas until it is reached.
