Magit? about tui.el HOT 4 CLOSED

Absolutely. The idea behind this package was to make it radically easier to build composable UI's for Emacs packages.

This library isn't production-ready yet though- something that is necessary for such a popular package as magit. I'm close to releasing a new version which has improved on the performance and fixed some stability issues.

Have you built anything with tui.el yet?

from tui.el.

Sounds neat! :)

No, I just discovered it recently by accident (don't remember how). I do have some ideas though:

• I'm pretty satisfied with how https://github.com/alphapapa/pocket-reader.el has turned out, but tabulated-list-mode leaves several things to be desired. It would be nice if tui could make such UIs easier and more powerful.
• In working on https://github.com/jgkamat/matrix-client-legacy-el, we've been considering trying to use lui for our UI, but I wonder if tui could work. Do you have any thoughts about components that might be useful for building a chat client? e.g. we need a header (currently provided by header-line-format, which may be the only possibility in Emacs anyway, since it must not scroll off-screen), an input area and prompt (currently provided by an overlay at the end of the buffer, which all messages are inserted read-only before), a last-seen line (currently provided by an overlay, which is manually moved to just before the prompt overlay), and a list of messages (currently provided by simply inserting read-only text, with text-properties to track message IDs, timestamps, etc).

That might be out-of-scope for this project, but some kind of next-gen UI paradigm for this kind of thing in Emacs would be exciting. :)

from tui.el.

Well I'm glad you did find it!

This the first I've heard about lui.el. Both lui and pocket-reader.el look really cool! I see that circe uses it too-- are there any other popular packages that do?

It's nice to aim for a clean functional style with component design, but the examples you mention might be circumstances in which there might not be an elegant solution. It's nice to have pure components, but really any logic could get thrown into a component (i.e. components could be written with deliberate side-effects in mind). You could set header-line-format in the :component-did-mount and :component-did-update lifecycle methods of your top-level component or define a dummy component that doesn't render anything and just changes the header.

I've been meaning to play around more with layout components (namely a grid-based layout mechanism). Imagine something like CSS Grid Layout, but for text in Emacs! More sophisticated layout could be achieved (such as headers and footers or even columns or pseudo-frames) without splitting windows :-)

I would say what you mention is not out-of-scope for this project (or at least not out of the realm of its intended usage). I probably won't include a dummy component that just sets header-line-format in tui.el itself, but I'm definitely open to iterating on the tui.el API to make it possible or easier to do wacky things! This library is all about experimenting.

Check out the links at the bottom of the readme to see examples of where I'm hoping to head with this. In particular- blessed has some pretty nice eye-candy.

I just pushed some of the changes I've made in the last two months to the dev branch- in case you're interested. I would love to hear how your experience is. I'm on Twitter as @ebanders.

from tui.el.

Hi, alphapapa. If you could please answer if lui.el from the Emacs Wiki is what you were referring to, it might be nice for the historical reasons for this issue.

The issue shouldn't be reopened, ebpa.

I'm just I was looking for disambiguation. I should've read further; circe lead me to the evidence that lui.el is the right reference.

from tui.el.