Pseudoterminal Widget

[lthoerner]

Problem

I'm having a lot of difficulty trying to emulate a terminal through a Paragraph widget in my shell project https://github.com/Eyesonjune18/rush. I think that it might make sense at some point to have a dedicated terminal widget that has built-in support for ANSI sequences etc.

Solution

• PseudoTerminal or Terminal widget type
• Would manage process input and output passthrough using stdin/stdout/stderr
• Support for interactive processes
• Support for shell prompts (maybe)

Alternatives

The alternative to having a dedicated widget for this is to use a Paragraph widget, but I've ran into quite a few problems doing so - especially in terms of the features mentioned above.

[joshka]

I wonder if you could do some of this this by implementing a backend that has a bit more of an escape hatch for just straight up treating the underlying terminal as a terminal. Something that delegates to an underlying terminal backend (crossterm/termion) do most of the heavy lifting, but still interrupts some of that for your feature.

Guessing that having to track the current line stuff is difficult? Is there an existing crate that can do some sort of fake ANSI buffer for you? That might make this easier.

[sophacles]

This is basically writing a full terminal emulator, similar to what Tmux or neovim terminal do. It would be a pretty cool widget to make, but a bit difficult.

Check out this post on how tmux is structured to get some ideas: https://www.quora.com/How-do-I-understand-the-tmux-design-architecture-and-internals

Key point is that it should attach the child process' stdin, stdout, and stderr to a psuedo-terminal before forking it (e.g. using the std::process::Cmd module and the openpty syscall, there's a couple crates for it). This is for a couple reasons:

• when bash launches a command and forks itself, it just shares the pty it's attached to for the child process. Many programs behave different when stdin/stout are a pty (vs some other type of file - like a pipe or an actual file), and so we'll want the terminal specific output.

• It allows for passing raw keycodes (etc) to the program and lets the widget intercepts what it wants (e.g. Ctrl-b in tmux) in an easy way.

• it allows for setting tty parameters (e.g. width and height) that the child program can use for it's sizing/rendering logic.

Parsing and processing the ansi codes from the program is an interesting task, not sure how to best approach that side of things without more research.

(see some more at these places:

• https://unix.stackexchange.com/questions/172506/how-does-bash-get-the-output-of-an-executed-program
• http://www.linusakesson.net/programming/tty/
• https://www.uninformativ.de/blog/postings/2018-02-24/0/POSTING-en.html
• https://poor.dev/blog/terminal-anatomy/

the last one is in rust!)

I think though, that this is a big enough complex enough task that it might be better as an independent widget in it's own crate - at least at first. Its the type of project that will be finding bugs for a long time and will probably benefit from a separate release cycle until the bugs become rarer for a while.

[joshka]

I think though, that this is a big enough complex enough task that it might be better as an independent widget in it's own crate - at least at first. Its the type of project that will be finding bugs for a long time and will probably benefit from a separate release cycle until the bugs become rarer for a while.

+1 to this idea generally. I don't think we have a specific guideline for what sorts of widgets should be within this library, but this particular widget seems like something that would be outside that (unless there were some clear benefits for a good chunk of users)

On the implementation front, it would also be worth looking at https://github.com/zellij-org/zellij

[a-kenji]

For anyone interested, I created a library for a PseudoTerminal Widget,
tui-term.

I tried to create multiple examples with various patterns, because there are a lot of possible strategies one can come up with, to handle this problem.

Its the type of project that will be finding bugs for a long time and will probably benefit from a separate release cycle until the bugs become rarer for a while.

Agreed! It would be great if people with those needs could end up testing and giving feedback, as I am sure there will be still a lot of edge cases uncovered.

It doesn't yet handle input at all and has the consumer handle it, but that is certainly also planned.

[joshka]

I'm going to convert this issue to a discussion as it's not likely that a terminal widget would be included in this crate as it's highly specific and makes more sense as a separate crate.