mirror of
https://github.com/wez/wezterm.git
synced 2024-09-20 19:27:22 +03:00
23b4876d75
I've noticed this off and on for a while, and thought it was something
fishy with my shell dotfiles.
Tracing through I found that the final byte in the "Face with head
bandage" emoji 🤕 U+1F915 was being interpreted as the MW control
code and causing the vt parser to jump out of the OSC state.
The solution for this is to hook up proper UTF-8 processing in the
same way that it is applied in the ground state.
Since we don't have enough bits to introduce new state values (we're
pretty tightly packed in the 16 bits available), I've introduced a
memory of the state to which the utf8 parser needs to return once
a complete sequence is detected.
|
||
|---|---|---|
| .. | ||
| src | ||
| build.rs | ||
| Cargo.toml | ||
| README.md | ||
vtparse
This is an implementation of a parser for escape and control sequences. It is based on the DEC ANSI Parser.
It has been modified slightly to support UTF-8 sequences.
vtparse is the lowest level parser; it categorizes the basic
types of sequences but does not ascribe any semantic meaning
to them.
You may wish to look at termwiz::escape::parser::Parser in the
termwiz crate if you're looking for semantic
parsing.
Comparison with the vte crate
vtparse has support for dynamically sized OSC buffers, which makes
it suitable for processing large escape sequences, such as those
used by the iTerm2 image protocol.