| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Even though the ST terminator is the only officially supported
terminator, some applications still rely on BEL to work properly. Both
have been supported historically, however there was no way for the
terminal to tell which terminator was used.
Since OSC escapes frequently offer the `?` parameter to query for the
current format, some applications expect the response terminator to
match the request terminator. To make it possible to support this, the
osc_dispatcher is now informed when the BEL terminator was used.
Since the C1 ST terminator was not yet supported for OSC escapes,
support for it has also been added.
|
| |
|
|
|
| |
This renames the generate_state_changes proc macro to include the `vte_`
prefix, since it's not useful to anyone other than our `vte` crate.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This completely removes the `codegen` project, which relied on outdated
libraries to parse DSLs to build the utf8 and vte state tables, to make
the library easier to maintain.
The utf8 table could be completely removed in favor of a `match`
statement, which also lead to a performance improvement with the utf8
parser.
The vte table did not benefit from `match` statements at all and instead
had significantly worse performance with it. To replace the old
codegeneration for vte, the `generate_state_changes` crate has been
created instead, which uses the language's proc_macro feature to create
a `const fn` which will generate the table at compile time.
|
| |
|
|
|
|
| |
This moves all crates in the workspace to the latest Rust standard and
resolves various style and formatting issues.
Fixes #32.
|
| |
|
|
|
| |
OSC parsing now handles UTF-8 arguments. 8-bit code support was dropped
to make supporting this easier.
|
| |
|
|
|
| |
Apparently 0x07 is frequently used. Not handling this causes SSH prompts
to never appear!
|
| |
|
|
|
|
|
|
|
|
|
| |
This adds a table-driven UTF-8 parser which only has a single branch for
the entire parser. UTF-8 support is essentially bolted onto the VTE
parser. Not the most elegant, but it does prevent the transition tables
from blowing up.
Instead of refactoring the syntax extension to handle both table
definitions, I've opted to copy/paste now for both simplicities sake and
because I can't see a clear path to a minimal shared solution.
|
| | |
|
| | |
|
|
|
When modifying table.rs.in, `cargo run` must be run in the `codegen`
crate. The result of expansion is included in the source tree so that
consumers don't need to pull in syntex just to compile.
|
