| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch overhauls the `Parser::advance` API to operate on byte slices
instead of individual bytes, which allows for additional performance
optimizations.
VTE does not support C1 escapes and C0 escapes always start with an
escape character. This makes it possible to simplify processing if a
byte stream is determined to not contain any escapes. The `memchr` crate
provides a battle-tested implementation for SIMD-accelerated byte
searches, which is why this implementation makes use of it.
VTE also only supports UTF8 characters in the ground state, which means
that the new non-escape parsing path is able to rely completely on STD's
`str::from_utf8` since `memchr` gives us the full length of the plain
text character buffer. This allows us to completely remove `utf8parse`
and all related code.
We also make use of `memchr` in the synchronized escape handling in
`ansi.rs`, since it relies heavily on scanning large amounts of text for
the extension/termination escape sequences.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When the params list for the CSI/DCS escapes is filled with all 32
parameters but ends in a subparameter, it would not properly stage the
length of the added subparameters causing the param iterator to get
stuck in place.
To ensure we always update the subparameter length even when no
parameter is staged after it, the length of subparameters is now updated
immediately while the subparameters itself are added.
Fixes #77.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since limits CSI parameters to be within range of `u16`, rather than
`i64`. This should effectively prevent downstream users from running
into DoS problems with excessively big escape sequence requests. An
example of a problematic escape would be `CSI Ps b` (repeat char).
According to https://vt100.net/emu/dec_ansi_parser, the smallest
possible size limit would be `16383`:
> The VT500 Programmer Information is inconsistent regarding the maximum
> value that a parameter can take. In section 4.3.3.2 of EK-VT520-RM it
> says that “any parameter greater than 9999 (decimal) is set to 9999
> (decimal)”. However, in the description of DECSR (Secure Reset), its
> parameter is allowed to range from 0 to 16383. Because individual
> control functions need to make sure that numeric parameters are within
> specific limits, the supported maximum is not critical, but it must be
> at least 16383.
|
|
|
This adds support for CSI subparameters like `\x1b[38:2:255:0:255m`,
which allows the combination of truecolor SGR commands together with
other SGR parameters like bold text, without any ambiguity.
This implements subparameters by storing them in a list together with
all other parameters and having a separate slice to indicate which
parameter is a subparameter and how long the subparameter list is. This
allows for static memory allocation and good performance while still
having the option for dynamic sizing of the parameters. Since the
subparameters are now also counted as parameters, the number of allowed
parameters has been increased from `16` to `32`.
Since the existing structures combine the handling of parameters for CSI
and DCS escape sequences, it is now also possible for DCS parameters to
have subparameters, even though that is currently never used.
Considering that DCS is rarely supported by terminal emulators, handling
these separately would likely just cause unnecessary issues. The
performance should also be better by using this existing subparam
structure rather than having two separate structures for DCS and CSI
parameters.
The only API provided for accessing the list of parameters is using an
iterator, this is intentional to make the internal structure clear and
allow for easy optimizations downstream. Since it makes little sense to
access parameters out of order, this limitation should not have any
negative effects on performance. The main drawback is that direct access
to the first parameter while ignoring all other subparameters is less
efficient, since it requires indexing a slice after iterating to the
element. However while this is often useful, it's mostly done for the
first few parameters which significantly reduces the overhead to a
negligible amount. At the same time this forces people to support
subparameters or at least consider their existence, which should make it
more difficult to implement things improperly downstream.
Fixes #22.
|
