I noticed while scrolling `emoji-test.txt` that some of the combined
emoji sequences rendered very poorly. This was due to the unicode
width being reported as up to 4 in some cases.
Digging into it, I discovered that the unicode width crate uses a
standard calculation that doesn't take emoji combination sequences
into account (see https://github.com/unicode-rs/unicode-width/issues/4).
This commit takes a dep on the xi-unicode crate as a lightweight way
to gain access to emoji tables and test whether a given grapheme is
part of a combining sequence of emoji.
This was an unintended casualty of the recent gui layer refactoring.
If you press `option-h` macos generates DOT ABOVE which we pass through
to the terminal key processing layer. It sees that ALT is set and emits
an escape byte (to indicate that ALT is set) followed by the UTF-8
sequence for DOT ABOVE. `zsh` gets confused and treats this as
`<ffffffff>` in its line editor.
This diff restricts the emission of the ESC leader to ascii alphanumeric
characters only.
There needs to be a followup diff to allow configuring how we process
these ALT modified characters on macOS because our current behavior
breaks eg: `ALT-1` which is a hotkey that I use in tmux. Granted that
I don't need tmux with end to end wezterm, but it does prevent me from
using that if I wanted to.
I thought that I'd broken something with the DEL processing in vim with
the new frontend but it turned out that the other frontend was emitting
BS always and that I'd actuall unbroken passing DEL through and that
other layers were translating DEL into an application cursor mode output
for DEL that emits a totally different sequence.
This diff preserves DEL and disables that other sequence.
Will follow up with some explicit configuration to control this
behavior, but in the short term, the default behavior should be much
closer to what people actually want and expect!
refs: https://github.com/wez/wezterm/issues/52
This is still a bit rough because the terminal parser doesn't
understand the pixel sizes, so it relies on the hard coded
cell dimensions being accurate.
This enables using large OSC buffers in a form that we can publish
to crates.io without blocking on an external crate. Large OSC
buffers are important both for some tunnelling use cases and for
eg: iTerm2 image protocol handling.
Repeated moves or wheel events are collapsed so that we don't clog up
the queue. The queue size doesn't matter as much as the latency of
processing a large queue. For fast or repeated moves the queue can grow
rather quickly, and with what is currently ~25-50 ms round trip per
entry for a remote session, that is a poor UX.
These codes are used to change the color palette, but if the `?`
string is used in place of a color spec, then we must respond with
the current color value string for that palette entry, so lets
implement that!
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
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.
