Comment by whacked_new
15 hours ago
I'm happy more people are interested in this critique! And thanks for d12frosted for joining the discussion.
I was searching for what's the latest in emacs widgets developments because I was interested in using widgets. Emacs Customize for example, renders text-based widgets in an editable buffer, which is very uncommon nowadays. Emacs seems like the best candidate for this kind of interactivity. I'm sure it's possible in other editors, but with significantly more effort and significantly slower rendering. I also considered lem, but the barrier also seems much higher.
His post also led me to his vui.el project, but I ended up not trying it, since after understanding the tradeoffs, I pushed the widget code creation to an LLM. I still get frequent unbalanced parentheses errors so I still stay close to the defaults.
The PoC is about testing a method to render a widgets-based, json-schema-validated input form that you can embed dynamically into an emacs buffer, enter the data, then do something post-validation. If anyone's interested, here's the latest state of the LLM-generated and human-fixed code: https://gist.github.com/whacked/6875c5117b48528e619755e13e24...
Thanks for sharing! The JSON schema → widget mapping is a solid use case, and your two-tier validation (keystroke + submit-time) is a nice touch.
On the unbalanced parentheses from LLMs - I've found Claude Code with Opus 4.5 is generally quite good at keeping them balanced, fwiw.
Curious about this though:
> after understanding the tradeoffs, I pushed the widget code creation to an LLM
What tradeoffs made you go with raw widget.el over vui.el? Genuine question - that's exactly the kind of feedback that helps me understand if vui.el is solving the right problems or missing something.
Your gist essentially reimplements some things vui.el provides generically (state tracking, inline form lifecycle, cleanup). Would be interesting to see if vui.el could simplify the widget/state parts while you focus on the schema translation - or learn what's missing if it can't.
If having conversation here is not convenient, we can continue under your gist or via email. Let me know if you are interested :) If not - that's also fine :)
The tradeoffs are very shallow, mainly I just wanted the maximum chance of seeing something working ASAP.
Staying vanilla reduces dependencies, which also makes testing easier during iteration. I forgot which agent (CC or codex) I used for the bulk of the code generation, but some times I manually do some one-off dialog and those get unbalanced parens.
In the agent I ask it to do `emacs -q -nw -l ...` to iterate, so it starts a bare emacs instance. This seems to have worked well when adding [Submit and Close] and [Cancel] buttons, as well as "move the cursor into the first text input widget when inserting a new array item" (the default action is to keep the cursor on the [INS] widget after inserting the list item).
The next consideration is just that I am less confident in the agent's ability to just ingest a .el library and use it correctly vs something more popular like python. Maybe it can, I just wanted results fast and not have to dig too deep myself. I had to go in and do some (setq debug-on-error t) toggles a few times while it was figuring out the json schema load into alist/hashmap differences and I didn't want to spend more time doing plumbing.
But as you probably can imagine, dynamic inline forms immediate gives us state issues, so I asked the agent to create a buffer-local alist (or hashmap?) to track the states of the form input, so it can be cleaned up on close. It's a bit unreliable now. If vui.el already has a solution I'll switch over next.