Is reconciling really make sense? about tui.el HOT 2 CLOSED

Hi, @cireu! Thanks for reaching out! I'd love to collaborate on improving the library's performance if you are interested.

I'd like to hear more about what algorithmic variations you have in mind. I recommend reading this article by Christopher Chedeau https://calendar.perfplanet.com/2013/diff/ for an overview on the basic React algorithm. The reconciliation algorithm is already quite simple and based on my experience with building large/complex UI's in Emacs is quite efficient compared to other UI logic like layout calculation.

So far in tui, I've relied on HTML-like elements as both as a familiar conceptual model and as an intermediate representation (like a dom/vdom). Could you describe a bit more what sort of architecture you are imagining? I'm super-interested in ideas about plain text interfaces. How does the UI model and a one-dimensional elisp buffer connect? Is there an intermediate representation of the UI? What happens if part of the UI/application updates? Does the entire UI re-render or just part? Are parts of the rendered UI cached elsewhere?

I know that's a lot of questions. No pressure about answering all of them; I'm just curious about the notion you have in mind about renders and updates. If you want to start spelunking in the tui code, one good spot is tui-marker-list.el - it's a doubly-linked list structure that's used for tracking segments of the rendered UI.

Also- if you have questions or want help with anything, feel free to open issues here, email me, or message me on Twitter ("[at]ebanders"). I'm going to keep this issue open for discussion about the dom/reconciliation.

from tui.el.

@cireu I'm going to close this issue, but please reach out if you'd like to discuss this topic further! Thanks for your interest :-)

from tui.el.