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.
The IME position is related to on-screen Window, not the
off-screen buffer.
Buffer
+- 0
|
| Window
| +- 0
| | (Tab bar)
+- 20 physical_top +- 1
| | (Terminal view)
| |
| |
+- 30 cursor.y +- 11 Correct IME position
It's too fiddly to setup in practice, and literally no one has
expressed an interest in using it.
Removing it simplifies some upcoming work.
Closes: https://github.com/wez/wezterm/issues/35
* take a stab at fixing the windows CI to generate 64-bit
* use actions-rs/toolchain more broadly
* fixup target dir for deploy script
* cut over to the rust action for installing rust
This makes the input behavior consistent with posix: if SHIFT is held
and a letter key is pressed, make sure that we treat that as the ascii
uppercase version of that key and that the SHIFT modifier is cleared.
