qwandor / anes-rs Goto Github PK

Understandably, emitting escape sequences to generate terminal mouse sequences is rather niche, but is it within the scope of this project? I'm thinking of using it as part of a terminal multiplexer for forwarding mouse events to pseudoterminals.

Version 0.1.6 provides:

pub enum Sequence {
    Key(KeyCode, KeyModifiers),
    Mouse(Mouse, KeyModifiers),
    CursorPosition(u16, u16),
}

Parser throws away every csi/esc sequence without known meaning (valid sequence, but we have no idea what it is). What's the problem. Any sequence, which isn't supported by anes is trashed and crate user doesn't even know it. Is this something we should expose? Should we add Sequence::UnknownEsc(char) & Sequence::UnknownCsi(Vec<u64>, usize, char)?

I want to use anes for Arduino serial I/O, but cannot, because it requires std. Can we make a no_std version of anes, or it's better to fork it?

Version 0.1.6 hides the State, Engine & Provide types. Basically the whole src/parser/engine.rs content.

• Should we move it into separate anes-parser crate for example?
• Like provide a crate with the parser only (no meaning, just input -> valid generic esc/csi sequence)?

While the License is documented on crates.io, many distros (e.g. Fedora) want an actual file as part of the package. Lawyers are very pedantic.

We parse all the input as u8 slice in the crossterm crate. It means that we are just matching byte sequences, but we don't know if the CSI sequence is (in)valid and thus we don't know if we should stop, start new sequence, etc.

Implement a two step parser:

• parse input as CSI, ESC, ... sequences without meaning
• give CSI, ESC, ... sequences meaning

You can check #15 where this kind of parser is being developed. It's gated with the parser feature.