Movwin: My (Unpublished) TUI Framework | Hacker News Reader

Movwin: My (Unpublished) TUI Framework

movq.de

51 pointszdw11 comments

Coincidentally I'm working on my own TUI framework for my book [1], so it's always interesting to see how other people approach it. I wouldn't, for example, use windows and drop-downs in the terminal; I think there are better approaches. Some of the most interesting text-focused UI experiments are taking place in Emacs and Vim, so that's where I'm taking inspiration from.

My framework is demonstrating the capability-passing approach to effects, which is the underlying architecture in most modern JS frameworks, Jetpack Compose, and "immediate mode" toolkits (though the authors are not necessarily aware of capability-passing as a concept). If you've read recent posts on "algebraic effects" or "effect handlers" it's in the same space. It makes for a quite pleasant user experience. I'm enjoying the work uniting theory and practice; one of the benefits of writing the book is I can justify these excursions.

[1]: https://functionalprogrammingstrategies.com/

I’ve actually implemented a TUI in Prolog (because there wasn’t anything in the space and I wanted to make sure it respected the relational/logical nature of Prolog). I’m happy with performance and developer ergonomics. But before I publish it, I want to firm up some opinions on how TUIs should behave for end users. Do you have any suggestions other than “use Vim/Emacs and think about it”?

TUIs in Prolog sounds fun.

The great thing about TUIs is that a simple text component is a universal widget. If the user can display text and capture events they can implement any interface components they want in terms of that.

That said, whatever the framework provides pushes users in a particular direction. The core of the things I'm thinking of (some links below) is providing easily accessible context for the user right at the point where they are working. This can be completions at the cursor, or a quick key to pop up a command palette. Fuzzy search is standard.

Here are some examples:

* Corfu: https://github.com/minad/corfu

* Vertico: https://github.com/minad/vertico

* which-key: https://github.com/justbur/emacs-which-key

* LazyVim: https://www.lazyvim.org/

I've included links that have screenshots showing how they work. The list is biased to Emacs, because I'm an Emacs user (Doom Emacs in particular) and so more familiar with that ecosystem.

Hope that helps!

This looks really nice in the screen-shots.

I'm working on what is effectively a fork of prompt_toolkit [1], which supports many modern terminal features I needed for euporie [2], such as terminal graphics, extra text styles, color palette detection, terminal clipboard, synchronized outputs, CSI-u, mouse pixel positioning, etc.

I'd be very interested to test it's performance and to read your code (I'm not an AI, promise :)

[1] https://github.com/joouha/euporie/tree/dev/packages/apptk

[2] https://github.com/joouha/euporie

> Startup time really is an issue with Python, because import is super slow.

Python has lazy imports coming soon in 3.15!

Source: https://docs.python.org/3.15/whatsnew/3.15.html#whatsnew315-...

This looks beautiful and I'm sorry the current state of affairs has made you not want to publish the code, I would love to play around with it. Regarding your decision to build - I feel you, I've had the same happen to me for everything from charting libs to various web components.

As an aside, I really like your web page - simple and clean with images and demos, no bloat.

I find it interesting that people still build and like TUIs that have menus and buttons. Trying to stuff a 1980s windowing paradigm into a terminal just seems odd to me. I never really liked the Borland interface. The article says that menus provide discoverability without having to read a manual, which is true, but at a cost of a whole line of precious text in the term and multiple keystrokes with modifiers to open the menu. Seems like a help key with a pop-up overlay could give you just as much discoverability. Anyway these Borland-style TUIs just keep hanging around. IMO, better to embrace something more like Emacs with built-in help.

There are plenty of examples where menu display and help texts can be toggled.

For example, aptitude has `Aptitude::UI::Menubar-Autohide` and midnight commander has options in the layout menu to disable menu/buttons/etc. That way beginners get to learn through discovery, and may later choose to switch to calling the menu/action with a keypress. Both of those respond to "standard" F1 for help too.

Would I prefer emacs M-x and C-h style interaction in mc? Yeah, probably. I'm used to it everywhere else(such as zsh). However, as a long term user I can execute basically all the functions even though I've long since disabled the buttons, menus and hints.

Yea, I get it. You can always disable things. For whatever reason, F1 has always felt very Microsoftish to me (and yes, I know it’s back to IBM CUA). All that stuff came from that PC era when everyone was still mostly using DOS and had serious Macintosh envy. So, sure, stuff Windows into a term screen. Note that it doesn’t have to be something with key modifiers like M-x or C-h. “?” would do it.

I wish instead of JavaScript and Python, more TUI investment went into compiled languages especially in Go.

if you're experimenting with the best menu UI I highly recommend taking inspiration from lotus 123

Reply on news.ycombinator.com