| Commit message (Collapse) | Author | Age |
| |\ |
|
| | | |
|
| | |
| |
| |
| | |
Fixes an issue with std not being disabled when building
vte without std feature.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The `no_std` feature has been broken since version `0.14`, since it did
not disable the `std` feature of `memchr`.
To fall more in line with the general ecosystem standards, this crate
changes the `no_std` feature into an `std` feature. Since `vte` should
be significantly faster with this feature, it has also been enabled by
default (previously `no_std` was default).
This is a breaking change, even if we ignore `no_std` consumers which
aren't able to compile 0.14, since intermediate dependencies relying on
the `no_std` feature will have to remove it from the manifest.
|
| | |
| |
| | |
See https://vt100.net/docs/vt510-rm/DECST8C.html.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The table based state change was too complex to make guesses why it's
getting slow and too fragile, as in modifying the amount of
states/actions were slowing down, even though, they were not used.
Rewrite the state + action change exactly how it's in [1] with respect
to our modifications/C1, etc. The new implementation is generally faster
than the previous one and is easier for compiler to reason about and
generate more efficient structures.
Also, the structure got way simpler to follow, since it matches the
spec pretty much exactly.
[1] - https://vt100.net/emu/dec_ansi_parser
|
| | |
| |
| |
| |
| | |
If the valid character was split across reads of partial utf8 and
got terminated by invalid byte, we should print it and advance, instead
of trying to discard it entirely.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |\| |
|
| | | |
|
| | |
| |
| |
| | |
Instead of collecting all the data into the vector just dispatch it
right away avoiding allocations.
|
| | |
| |
| |
| |
| |
| |
| | |
This patch bumps utf8parse/vte_generate_state_changes versions to
release the change which included the license files into the crates.io
package.
Closes #113.
|
| | | |
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Modern usage of this control function comes from the BiDi draft
proposal:
https://terminal-wg.pages.freedesktop.org/bidi/recommendation/escape-sequences.html
The draft slightly extends the definition in ECMA-48.
Signed-off-by: Mohammad AlSaleh <CE.Mohammad.AlSaleh@gmail.com>
|
| |/
|
|
|
| |
These functions were initially implemented in
https://github.com/alacritty/alacritty/pull/4763
|
| | |
|
| | |
|
| |
|
| |
Fixes #100.
|
| |
|
|
|
|
| |
The modes could overlap and there's also no way to actually
forward information about unhandled modes downstream, thus
split the modes into 2 separate structures and pass unhandled
modes.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Given that an example of the translation table is not present by xterm
and they provide only script to generate one from the running X11
system, the example of the output is also included in the repository
now.
Co-authored-by: Christian Duerr <contact@christianduerr.com>
|
| |
|
| |
See alacritty/alacritty#6845.
|
| |
|
|
|
|
| |
This just adds handling of the CSI u escapes mentioned in the spec
and don't provide key to escape sequence transformation for the terminals.
Links: https://sw.kovidgoyal.net/kitty/keyboard-protocol
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
The OSC buffer limit was set to 1024 bytes by default for no-std
targets. Especially when operating in a restricted environment where OSC
escapes are irrelevant, this consumes a lot of unnecessary memory.
This patch adds a const generic that allows controlling the target size
of the OSC buffer at compile-time, making it possible to remove the
buffer entirely if OSCs are not required.
Co-authored-by: Christian Duerr <contact@christianduerr.com>
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Signed-off-by: Andy-Python-Programmer <andypythonappdeveloper@gmail.com>
Signed-off-by: Anhad Singh <andypythonappdeveloper@gmail.com>
Co-authored-by: Nicholas Sim <nsim@posteo.net>
Co-authored-by: Christian Duerr <contact@christianduerr.com>
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Much like `std::ops::Range`, we likely don't want this to be `Copy` as
that makes it too easy to get mixed up on what state you are using but
`Clone` should be explicit enough to be safe.
`PartialOrd` / `Ord` were left off because there isn't really a
user-facing ordering to these types
`Hash` was left off as the use cases for it isn't clear.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
This changes the test code to use only a single dispatcher instead of
having a dispatcher for every single type of escape sequence.
This makes it trivial to test transitions between the two separate
escape sequence types.
|
| |
|
|
|
|
| |
This resolves a bug when transitioning between DCS and ESC sequences,
which would cause the intermediates of the ESC dispatch to contain data
from the DCS sequence.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
I've noticed while playing around with vte in a personal project, that I
didn't need all of the methods of the `Perform` trait. In Alacritty we
also don't react to everything and other crates like
`strip-ansi-escapes` basically doesn't respond to anything.
Of course it's always easy to just copy/paste the entire trait and move
on, but I think it's probably worth making the life of downstream easier
by not enforcing this.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|