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.
I got to the bottom of the hang on startup when trying to connect
to the multiplexer on windows and it was because of the change
in 367a44fb96 to try to drain the pollable
channel.
This mapped to ReadFile on windows which always tries to fill the buffer
even if it is a socket under the covers.
348421b010
teaches filedescriptor to use the recv/send if the filedescriptor is
really a socket and that resolves the hang.
While debugging on windows earlier today I saw that we were
blocked on this wait on the main thread. For whatever reason,
that only blocks in practice on Windows; I suspect that this is
due to a timing issue on windows where the server side takes
longer to respond than it does on posix.
