Heads up display around my existing terminal? Or terminal in terminal?

[evbo]

Is there a way to use tui-rs to create a sort of "heads up display" around my existing terminal command line prompt?

For instance, I should be able to type standard unix commands, access environment variables, etc, all from a typical user input that looks just like a terminal, but then in the upper sections of the window there would be TUI widgets that perform auto-complete suggestions and other quality of life features to help the user formulate the commands they are trying to run.

For instance, let's say my hypothetical tui-rs application knows about a binary called "desert_locator". When you start typing a desert_locator command, it preempts your input providing suggestions like the following:

_____________________________
|Suggestions (click to autocomplete):
| tapioca
| tap syrup
|____________________________



$user: dessert_locator tap         <-- here is a conventional command line prompt (run ls, grep, etc...)

The key answer I'm looking for: Does this library allow me to still let the user interact with their existing shell/environment in a non-intrusive way? Or would I have to emulate a terminal, passing all user input into a subprocess from Rust and then handle all stdout/stderr?

[joshka]

Sounds like you're after something like what fzf does, but for man pages?

In theory you could probably launch your tui app from the shell and pass it a fake terminal that is a wrapper around the real terminal backend but with a constrained area to render on. (Create a new backend that implements the terminal trait and passes everything on to an inner terminal field except the sizing).

But all input from the stdin will end up handled by the tui app not the terminal. You could use a similar mechanism to what fzf uses to pass this back to the shell once you're done with your command. E.g. take a look at https://github.com/junegunn/fzf/tree/master/shell for how this is done in fzf. I think in some cases this just runs the command, but it's possible that the command is passed back to the shell's command buffer.

It really seems like what you're asking about can be better implemented by code outside your app calling in rather than the your app wrapping the terminal. Id encourage you to spend some time looking at how your shell supports these approaches as well as what you can do with terminal multiplexers like zellij or tmux.

[evbo]

thanks, as I understand it, multiplexers isolate your terminal into panes but I would need to generate auto-completion suggestions based on user input in one of those panes.

calling in is a cool idea, but then I would need to have a way of wrapping each CLI so that it called my ratatui app and I don't control the code. So wrapping the terminal feels like the only way, but I have zero experience with this sort of thing so maybe I'm just not seeing the simpler path yet.

[joshka]

Can you perhaps document your use case a bit more? It's difficult to provide advice as we might be experiencing a bit of an XY Problem here.

[evbo]

sure, although I might be blind as to what details I should be including just given my newcomer status to TUIs:

• user decides to load my TUI app, runs it like any other binary from the command line of their (bash) shell
• TUI app loads in (separate?) terminal window
• They have a command line interface as shown in pic above.
• They type "dessert_locator" and that input gets detected by the TUI app, which in turn decides it knows common arguments to that particular command
• The user starts to type a dessert, "tap", and the TUI app displays common desserts related to "tap" above their command line prompt region of the screen
• The user types ALT + Up to scroll the list of autocomplete suggestions and ALT + Enter to select "tapioca"
• They then hit return and the command dessert_locator 'tapioca' is sent to the Linux kernel, which runs the dessert_locator binary on the path and in turn standard streams begin returning
• The TUI app knows about these standard streams and prints them a little ways above the command line interface, but not too high up since that would collide with the autocomplete suggestions
• After a while, the user decides to terminate the TUI app, which gracefully returns the user back to their original shell. Bonus points if all environment variables and other context set in the command line interface of the TUI app return to the original shell seamlessly, but that would be nice to have.

That's more or less the use case. Does that make sense?

[joshka]

I think I'd implement that by looking at what fzf does - e.g. let the shell call you, not you call the shell.
Writing your own shell / terminal has too many edge cases to get right. Looking at https://github.com/wez/wezterm/tree/main/termwiz might give you an idea of what it takes (note the 413 open issues ;))

Using fzf, the majority of this might be as simple as writing a helper command that handles how to complete commands. That command just needs to output a list of autocomplete values. fzf handles the selection part. If you want it to also have a UI in another window, take a look at fzf --preview perhaps? Or duplicate the fzf approach perhaps. Not sure how you'd handle the persistent part of this though. I don't quite understand the value of it though.

Is this really a dessert_locator, or is there an actual specific use case that you're thinking of making easier here?