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.
A big paste could saturate the input/output of the pty and
lead to an effective deadlock; the application wants to send
output to us but we are busy trying to write the paste to it.
Break up large pastes into chunks and send them piece by piece.
This does mean that a large bracketed paste is not an atomic
unit any longer, but it seems to work out ok when pasting into
vim.
We were incorrectly treating it as \r\n, but it should only have
been moving vertically.
This fixes the positioning of the cursor when using eg:
`dialog --yesno hello 0 0`
Without this change, the cursor would be way over to the left.
With this change, the cursor is correctly positioned inside
the "YES" box.
In the case where the screen was enlarged, we don't eagerly resize
the line vectors.
If a subsequent erase display occurred, we'd only erase to the old
size of the lines, rather than the new size, which could result
in a black square in the upper right corner of the display.
Repro scenario is:
* resize window larger than initial height
* `dialog --yesno hello 0 0`
The dialog background should fill the display.
This was responsible for eg: dialog rendering a black (or whatever
the default background color was) strip behind the text in an
invocation like:
`dialog --yesno hello 0 0`
Rather than render a default cell, render a blank cell using the
current pen.
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.
My original idea was that I would centralize of the key binding
logic in the terminalstate, but this places a bit of a burden on
the TerminalHost portion of the interface.
In particular: when running a multiplexer server we may be headless
or have multiple heads. In that scenario we want the terminal
to be backed by a virtualized screen, and that means removing
the direct callback to access eg: the host clipboard. This
diff is the first of a couple that have the goal of removing
those sorts of dependencies.
This is an unfortunately large diff that:
* Separates Tab ownership from TerminalWindow
* Introduces a Mux container for all of the tabs in the application,
across all windows
* Moves ownership of processing pty responses to the mux; it sets
up and has logic to process data for the ptys and apply to the
tabs
I've moved the logic for processing new tab and new window hotkeys
to the TerminalWindow's themselves as we need some context to
associate the tab with the right window and to create a new window.
I think that will simplify and allow unifying more code.
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.
There isn't really any reliable consistency in the virtual_keycodes
being set for simple keys or shifted keys, so we need to go all in
and add our own scancode processing as a fall back.
This makes it even harder to process unicode input, particularly
because we have no idea whether a ReceivedCharacter event will
follow.
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.
