1
1
mirror of https://github.com/wez/wezterm.git synced 2024-11-10 06:34:17 +03:00
Commit Graph

8 Commits

Author SHA1 Message Date
Wez Furlong
a42342ce0c Recognize C1 codes encoded as UTF-8
These are used in the default Fedora 31 bash profile, so it seems
worth handling even if they are a bit amgiguously defined.

Closes: https://github.com/wez/wezterm/issues/86
2019-12-28 10:33:24 -08:00
Wez Furlong
662227a725 bump vtparse version for publishing 2019-12-21 16:43:13 -08:00
Wez Furlong
ff4f0add98 clippy 2019-12-15 08:50:12 -08:00
Wez Furlong
23b4876d75 fix an issue with utf-8 in OSC sequences
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.
2019-11-03 22:01:35 -08:00
Wez Furlong
ed5dcd71da vtparse: document things 2019-06-29 19:13:45 -07:00
Wez Furlong
5440cbe521 replace vte with our own vtparse crate
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.
2019-06-29 16:28:39 -07:00
Wez Furlong
192eaeb3ff vtparse: Add utf-8 support 2019-06-29 16:15:15 -07:00
Wez Furlong
2361d88c2a initial take on a low level vt parser
This is based on the state machine described by
https://vt100.net/emu/dec_ansi_parser

and the public domain C implementation:
https://github.com/haberman/vtparse
2019-06-29 15:21:09 -07:00