Include the ANSI escape sequence that caused the instantiation of an events.Key in the events.Key class

[barisione]

From what I can see in src/textual/_xterm_parser.py and src/textual/_ansi_sequences.py, ANSI escape sequences get parsed and generate instances of events.Key as needed.

My terminal widget needs to generate ANSI escape sequences back from key events but this is non-trivial if you want to support different terminals. This could be easier if events.Key had an optional field containing the original ANSI escape sequence.

[github-actions]

We found the following entry in the FAQ which you may find helpful:

• How do I center a widget in a screen?

Feel free to close this issue if you found an answer in the FAQ. Otherwise, please give us a little time to review.

This is an automated reply, generated by FAQtory

[willmcgugan]

Not opposed to it. But there isn't a one to one mapping of key events to escape sequences. Might complicate things.

When you say terminal widget, do you mean a terminal widget that runs inside Textual ?

[barisione]

Not opposed to it. But there isn't a one to one mapping of key events to escape sequences. Might complicate things.

Yes but what I was suggesting is that you don't discard the initial information on the escape sequence instead of reconstructing it. This way the sequence should be correct for the specific terminal in use as that terminal sent it in the first place.

When you say terminal widget, do you mean a terminal widget that runs inside Textual ?

Yes, using pyte. I'm aware there's already a similar 3rd-party widget but it's GPL3 so I cannot use it (or look at its code!).

For now I'm just converting key strokes in a naive way. For instance, if I get an "up" key I alway send "\N{ESCAPE}OA" to the TTY for the program running inside the terminal.

[willmcgugan]

I don't think this is practical, given the somewhat inconsistent ways terminals deal with keys.

[github-actions]

Don't forget to star the repository!

Follow @textualizeio for Textual updates.