I noticed that things were feeling laggy in general and when I
added some debugging prints I noticed that we were getting a
continuous stream of CursorMoved events with the same coordinates
while the window had focus.
This diff short circuits mouse processing in that situation and
makes things feel a bit more snappy.
When repainting the screen, we must be sure to set the cursor
to the right shape.
While the repaint is happening, hide the cursor to prevent
the cursor jumping around while the repaint happens.
Extract the code that builds a `ProbeHintsBuilder` from the environment to a
separate `ProbeHintsBuilder` constructor. This allows callers to re-use the
environment-based `ProbeHintsBuilder`, but override other aspects of
`ProbeHints`, e.g. to disable mouse handling.
When repainting a surface, we optimize for the case where lines are simple text
by combining the the `Change::Text` for the end of the previous line and the
start of the next line into a single `Change`.
The assumption about relying on automatic margins is incorrect. We can't rely
on them, as they might be disabled, and in any case they are no use if the
previous line was shorter than the full width of the screen.
This results in the lines appearing joined together on a single line. This is
evidenced in the existing tests where `"hel\nw"` becomes `"helw"` on a full
repaint.
The solution is to always inject a real CRLF by adding a `CursorPosition` change.
This replaces any CRLF that may have been swallowed by the `Surface` when it
added the original changes.
`input_parser.decode_input_records` might not add anything to the input queue,
e.g. if the input event is one that is being ignored. In this case, we must
loop round and wait again for more input.
Remove the dance for appeasing the borrow checker. The borrow checker can
be appeased by borrowing the `input_queue` field directly.
Application cursor keys are a separate set of encodings that applications can
ask the terminal to produce for cursor keys.
Unfortunately, PuTTY generates these for shift-modified cursor keys. If an
application is to distinguish between normal and shift-modified cursor keys
on PuTTY then it will need to be able to distinguish between normal and
application cursor keys.
Add new `KeyCode` variants for application cursor keys.
Add two new `Change` variants: `ScrollRegionUp` and `ScrollRegionDown`, which
scroll part of the screen up or down by a number of lines.
On Unix, these are implemented using the `change_scroll_region` and
`parm_index`/`parm_rindex` terminfo capabilities if available. If `parm_index`
or `parm_rindex` are not available, but `scroll_forward` or `scroll_reverse`
are, then these are used repeatedly to get the same effect.
On Windows, these are implemented using `ScrollConsoleScreenBuffer`.
If the cursor has been made invisible (by setting the shape to `Hidden`),
then in order for it to be visible when it is reset to the default shape,
it must be made visible. This can be done by rendering the `CursorVisible`
sequence.
Where supported, the `CursorNormal` sequence can be rendered to do
both `CursorVisible` and `ResetCursorStyle` in one go.
This reverts commit 8dcf3cb21e.
My experience with even getting in the door with snaps was sub-par.
The submission/review process seems under specified and under staffed.
The tools for producing snaps were also rather broken in the case
that your PATH doesn't match a blessed configuration. This was
hard to discover and expensive to iterate on.
My conclusion is that snaps are not for me.
When enabled, the windows version will use winpty rather than conpty.
This potentially allows running on older windows versions but has
a few caveats:
* Requires winpty.dll and winpty-agent.exe be in the PATH
* The initial screen / cursor position looks funky for me with the
latest release of winpty, but that is from a couple of years ago
* Mouse reporting doesn't work, perhaps for the same reasons that
it isn't working in conpty.
I want to make this into a runtime selectable feature before tidying
up the installation aspects; we need that plumbing anyway to be
able to select between local and remote mux'd tabs.
conpty, while it may be the best native API available for consoles
built in to Windows 10, currently swallows mouse escape sequences
(https://github.com/Microsoft/console/issues/376) so we need an
alternative for a better windows experience.
winpty appears to be a reasonably mature pty implementation, so
let's try that!
I tried to use winpty-sys from crates.io but it requires the
installation of an external clang compiler so I used bindgen
on my linux box to convert the small header file to rust and
then tweaked it a bit.
This commit includes that basic wrapper plus a type safe layer
on top.
This will require distributing the dll and an agent helper along
with the wezterm.exe.
This commit doesn't implement the wezterm side of the pty interface;
that will be in a follow up commit.
