ebpa / tui.el Goto Github PK

Hi ebpa,

Thank you for creating the tui.el library. I have a question about its usage:

I expect to force update the component with a timer, then reassign the time-string value, and have the interface automatically redrawn, but it did not automatically re-render. Here is an example code:

(tui-defun-2 time-test (&state (time-string (current-time-string))
                           (timer (tui-run-with-timer
                                   component 1 1 t
                                   (lambda ()
                                     (tui-force-update component)))))
  "A basic timer test"
  (tui-span
   (format "\ntime: %s" time-string)))

(setq time-test-comp (time-test))
(tui-render-element time-test-comp)

I have tried to solve this issue on my own, but have been unsuccessful so far. Can you please provide some guidance or suggest a solution?

Thank you for your time and help.

Hi!

I was starting playing around with your library and I noticed that in the latest release you always return t in tui-render-element: is that intended? It seemed useful to get the element reference :p

Thanks for this work!

I was able to get TUI to render a timer in IELM, which is impressive enough for me.

I think it would be a good idea to compare this library and its goals with the built-in Widget Library, as there are differences that would be interesting to see when someone is looking for a TUI-like library, or a component library for making interfaces and forms of some sort... application programming within Emacs in general, I suppose.

At the moment, I'm using the Widget Library, but I'm having difficulty with some of its documentation and some of its behaviour, but otherwise I think it meets my needs more appropriately than TUI. I may be wrong, however!

If TUI provides buttons, editable fields, lists, most of what Widget provides, then I might try implementing my setup-buffer in TUI instead.

What do you think, Erik? I think it'd be good for the README section where you mention other similar projects, Emacs and non-Emacs.

Hi there,

Just a wild, crazy, huge, vague thought: what if Magit could be implemented with this package? Or to put it another way, what if this package implemented the same kind of components that Magit has? That would be pretty cool. :)

It's been a while hearing an update on this project.
Is it still active?

Hi Erik,

(tui :location
     (recipe :fetcher github
             :repo "ebpa/tui.el"
             :files ("*.el"
                     "components"
                     "layout"
                     "demo"
                     "snippets")))

I can't find Tic Tac Toe with find-function or with describe-function. I verified that the file was downloaded and installed, even compiled (I do see tui-tic-tac-toe.elc)...

...I looked through tui.el and demo/tui-demo.el, neither of which (require 'tui-tic-tac-toe)...

...some further searching with Helm dir smart search revealed that only tui-demos.el requires Tic Tac Toe, itself not required by tui.el or demo/tui-demo.el.

It looks like you just need to pop that require line from tui-demos.el to demo/tui-demo.el and that should fix the issue.

Otherwise Tic Tac Toe is unavailable in 0.4.0 0.0.4 (semv-ver would say the prior, btw).

Hi, I saw your EmacsConf talk on tui.el and thought I'd give it a whirl, as I'm trying to build more interactive tooling on Emacs.

Based on the README, I eval'd this code:

(straight-use-package
 '(tui :type git :host github :repo "ebpa/tui.el" :files ("*.el" "components" "layout" "demo" "snippets")))

(require 'tui)

The require fails with an error:

Debugger entered--Lisp error: (void-variable tui-element-outline)
  byte-code("\302\10\301 \303\304\11!$\207" [tui-element-outline element tui-defun "Structure outline of ELEMENT and its children." tui-element-outline-string] 6)
  require(tui-dev)
  load-with-code-conversion("/home/ieure/.emacs.d/straight/build/tui/tui.el" "/home/ieure/.emacs.d/straight/build/tui/tui.el" nil t)
  require(tui)
  pp-eval-expression((require 'tui))
  pp-eval-last-sexp(nil)
  funcall-interactively(pp-eval-last-sexp nil)
  command-execute(pp-eval-last-sexp)

I assume this isn't expected behavior. Is the README current?

Hi ebpa! I' m interesting on your project because I' m looking for a framework to create extensible UI program.

I am wondering dom node reconciling doesn't worth its overhead while rendering. I have to claim that I'm not a regular frontend developer, but I investigate some famouse frontend UI framework like React, Preact, Vue, etc.

These framework do the Vdom reconciling because directly rewrite real DOM is expensive. Vdom diff can help reduce operation on real DOM.

However, we present our UI in Emacs buffer. operating Emacs buffer is lightweight because buffer data structure is tightly integrated with Elisp VM(unlike DOM object, which is far away from JS engine). We just need one call to "insert" and "delete-region" to update the buffer no matter how large the content is. What's worse, reconciling algorithm must implemented in Elisp, which is more complicated and slower than a native function call.

My guess is: Reconciling is over-complicated, We just delete original content and insert new one. It must be admitted that my argument lacks performance test data, so I'd like to dicuss this with you. Do you have any ideas on this? Thanks a lot!

A picture is worth a thousand words, and screenshots are certainly the first thing I look for when I am looking at a UI package. If you like I can load up your demos and make a PR?