We need to set the terminal to blocking mode when we want poll_input
to block forever, otherwise we immediately receive WouldBlock error
response and quit the program.
This one has been bugging me for a while; we now know when we've
wrapped a line and can join it without a line break when double-clicking
to select a word.
This commit introduces a wrapped attribute to help record this
information, which could potentially help with when it comes
to looking at nicer resize behavior in refs: https://github.com/wez/wezterm/issues/14
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 was an off-by-one issue when using scroll margins just shorter
than the screen and when scrollback is enabled.
Added a unit test to verify the behavior.
I've had mixed results with esctest; the IRM and cursor save/restore
tests fail for me in terminal.app, iterm2 and xterm, and fail in the
same way on wezterm, so I'm not sure if I'm not running those tests
correctly. However, they did encourage the discovery of some other
real issues in the wezterm emulation.
These were showing up as unrecognized sequences on my mac, and I
wondered what they were. We now parse them and do nothing with
them, other than print out the parsed form :)
I wanted to see how much work remains to enable iterm2 image
display; one of the blockers was a limit in the size of the
buffer in the vte crate, which has been removed in my fork
of vte.
As part of testing our ability to absorb that data, I found
a couple of issues with applying the image cells to the display,
so this commit also takes care of that.
We still don't have code to connect the cell image data to the
opengl render layer.
The saturating_sub was going to be an attempt at the look-back alluded
to in the TODO comment, but I decided not to implement that in this
iteration.
The effect of this was that double clicking the `m` in a sequence like
` master` would only select the `m` instead of the `master` string.
previously this just used unicode word segmentation rules, but that
is insufficient for most technical users.
Change this to look for sequences that are non-whitespace and not
enclosed by bracket/quote delimiters. This allows selecting file names
with a double click, which was my main issue.
We don't yet have any code to render them, and the vte parser seems
to truncate incoming image sequences ~1kb in size, so more work is
needed to make this useful.
