[Question] any plans to allow integration with TUI?

[marques-work]

Hi there, what's the feasibility of supporting an integration with a TUI framework like tui-rs? TUI frameworks generally ~want~ assume full control of the terminal (like reedline, tui-rs uses crossterm) so that it can draw boxes, capture mouse input, etc.

It would be awesome to create TUIs where a pane (i.e., a positioned and size-constrained box) could have readline input capabilities. There don't seem to be any readline-like libraries that can do this right now, presumably because implementing readline requires some low-level control of the terminal which is at odds with allowing other library to assume that control.

Having not built this myself, all of this is just speculation: I think, for the most part, the capabilities needed to work well with TUI frameworks would be to allow the arbitrary positioning and sizing of the buffer (such that readline does not assume it starts at x:0, y:0 nor has the full terminal width) and allow another framework to capture/handle mouse events before passing through key events to reedlne.

I hope I'm making at least some sense. If this enhancement could be aligned with the goals of reedline in some way, I'd be happy to help implement it (though I'm sure I'll need some time to ramp up since this is not my domain of expertise).

[sholderbach]

We currently focus our efforts on the regular scrollable "continuous paper in the teletype" mode of the terminal. Most of the tui-application build their stuff in the "alternate screen" mode. Here they have more finegrained control about where stuff gets printed, mouse events, and control the behvaior on scrolling with the wheel (and the terminal doesn't provide the regular scrollback buffer). Being a component in such a framework would likely require us to cooperate with particular APIs they provide. So we havent explored that space yet. It is definitely currently lower on the priority list for us compared to the best possible experience in the general scrolling environment.

There are some solid crates that support general line editing inside a tui component e.g. dialoguer (in conjunction with console) For tui-rs there is https://github.com/rhysd/tui-textarea (don't know if that exactly fits your bill)

[marques-work]

Thanks for the reply @sholderbach -- and from a priority standpoint, that makes sense. I'll take a look at these options (though, I would love something that could actually provide an editing experience very close to GNU readline). I also know that even if I did implement that in this repository, given priorities, I might be creating more work by obliging you to review and possibly support this in the near future.

So I will see how this goes :).

[sholderbach]

While most of the painting (including the terminal size related calculations are extracted into the Painter the reading of key events from STDIN is currently part of the core event loop. I haven't looked into how the requirements are in a TUI environment for that. It would certainly be nice to be able to provide the rich language support features around highlighting and completions for TUIs as well.

[marques-work]

Thanks for the insights. This weekend I may play around with reedline to 1) get familiar with the codebase and 2) see what it would take to achieve this in a way that won't break the interface/current usage.

As an aside, is there a features table of what has/hasn't been implemented compared to GNU readline? I think I'd be interested in bringing in any missing functionality too, in my spare time.

[sholderbach]

That we don't have formally. Currently only our issues are indications on what to work on. We also don't necessarily strive to be feature compatible to GNU readline, especially when it comes to the interactive feature we draw more inspiration from fish's line editor defaults and from zsh's zle.