Comment by d12frosted | Hacker News Reader

Comment by d12frosted | Hacker News Reader

Parent Full thread

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.

Thanks for the detailed response! This is really helpful feedback.

Looking at your gist, I think the code actually illustrates why I built vui.el in the first place. The schema→widget mapping logic is genuinely interesting work, but a significant chunk of the code (~400 lines) is dedicated to the inline form lifecycle: jsf--inline-forms registry, marker tracking, resync passes, advice on widget-before-change, overlay cleanup, etc. That's exactly the plumbing vui.el handles automatically.

With vui.el, your json-schema-form could potentially be just the schema translation + a component wrapper:

    (vui-defcomponent json-schema-form (schema on-submit)
      :state ((values (schema-defaults schema))
              (errors nil))
      :render
      (vui-vstack
       (render-schema-fields schema values
         :on-change (lambda (path val)
                      (vui-set-state :values (set-at-path values path val))))
       (vui-button "Submit"
         :on-click (lambda ()
                     (let ((errs (validate-schema schema values)))
                       (if errs
                           (vui-set-state :errors errs)
                         (funcall on-submit values)))))))

State tracking, cleanup on close, multiple forms per buffer - all handled by the framework. Your validation logic and schema mapping would be the same, just without the infrastructure code.

On the emacs -q -nw workflow: it works, but you might find eldev + buttercup tests even better for AI-assisted iteration. The agent can run eldev test after changes and self-correct on failures. Byte-compilation catches issues too. Claude Code handles eldev well out of the box.

Anyway, not trying to hard-sell vui.el - your approach clearly works and the schema-form idea is cool. But if you do hit more state/cleanup headaches, might be worth a look. Happy to help if you want to try porting the schema logic over.

I played with vui.el's hello world code earlier today, and it's a great showcase!

Is there a simple way to achieve in-buffer forms? The jsf-- stuff was instructed to make the widget form read-only except for the interactive widget components (took a few iterations to work), while keeping the rest of the buffer editable. The demos seem to all mount to a new buffer. Though I could also feed vui.el into an agent and ask :-)

Thanks for the tips. I guess I can add the deps to --eval "(load 'eldev)" in manual testing.

edit: wow, I just saw your implementation at https://gist.github.com/d12frosted/51edb747167c0fa8fcce40fed...

this is awesome!

Glad you like it! I was curious to see the comparison myself, so I asked Claude Code to reimplement it with vui.el - wanted concrete numbers and code rather than just claims. The 60% reduction was a pleasant surprise.

Regarding in-buffer forms: I'd love to understand your use case better. When you say "injecting" forms into a buffer while keeping the rest editable - what's the actual workflow you're building? A few scenarios come to mind:

1. Inline editing in org/markdown - e.g., a structured data block that becomes a form when you enter it? 2. Mixed content - documentation with embedded interactive widgets? 3. Progressive disclosure - expand a section into a form, collapse back when done?

Right now vui.el mounts to a dedicated buffer, so it doesn't support inline injection. But depending on the use case, it might not be too complex to add - or there might be a different approach that works better. Would be interested to hear more about what you're trying to build.

(And yes, feeding vui.el to an agent works surprisingly well - that's exactly how the gist was created!)

I haven't thought through the entire use case. But it loosely revolves around the interaction designs provided by org-mode, ipython/jupyter notebooks, atuin desktop, aka "interactive documents", where the execution intent is embedded in text.

Jupyter is objectively more powerful from an interactivity standpoint, but the cell-based editing strategy has always fell short from a navigation and versioning standpoint. OTOH text-only interaction is sometimes too free, so after all these years, I still haven't found anything that feels just right.

Say you are writing devops documentation. Skipping the many ugly ways you can achieve this in jupyter (e.g. you need ssh logins and creds), or even slightly less ugly in atuin, in org-mode you'd use a begin_src / end_src block and eval that block. The block kind of breaks the text flow. A possibly better interaction mode would be a text "button", borrowing from GNU Hyperbole's terminology.

Continuing the button use case, say the devops document says "<run this> to check the uptimes of our servers". That button is simple enough. You can evaluate this and get a buffer, or like org-babel, insert the output into a block inline. Now we want to extend the functionality: "<query the ps of a given server>". We want parameterization, but without breaking flow. So here I'm thinking of injecting a disposable form at cursor. In a web-based toolkit, we'd use a popup or expandable form, but that switches focus out of the document and into a modal. Does that make sense?

I'm not sure how well it will all fit, but every now and then I feel the same itch, and it seems like in 10+ years of using different tools, Emacs is still the best for providing "structured, validated input for in-document interaction".

This makes a lot of sense now - thanks for the detailed walkthrough.

So the core idea is: ephemeral, inline forms that appear at point, collect structured input, execute, and disappear. Not persistent multi-form buffers, but disposable parameter prompts that don't break document flow or switch context to a modal.

The <query the ps of a given server> example is perfect - you want:

  1. Click/activate the button
  2. Small form expands inline (server selector, maybe filters)
  3. Fill, submit
  4. Form vanishes, result appears (inline or in separate buffer)

This is actually more tractable than what the gist's inline extension was doing. That was about persistent forms with state tracking, cleanup on manual deletion, etc. Your use case is simpler: mount form at point → collect input → unmount → done.

vui.el doesn't support this today, but it's not a huge leap. The pieces are there:

  - Components with state and validation 
  - Controlled rendering 
  - What's missing: mounting into an existing buffer at point (vs taking over a buffer)

I'd need to think through how it interacts with the host buffer's text properties and undo - that's where the gist's widget-before-change advice complexity came from. But for disposable forms that clean up after themselves, it should be simpler.

If you want to experiment with this, I'd be curious to collaborate. It's a use case I hadn't fully considered, but "structured, validated input for in-document interaction" is a good framing.

I spent some time reorganizing the code in my gist into a repo for better change tracking at https://github.com/whacked/inline-interactive-forms.el

I also pulled vui.el into the dev setup and basically instructed the agents to reach feature parity. I ran out of CC credits fast so switched to codex. Codex makes a lot of unbalanced parenthesis mistakes even in agent, although it does eventually get it right by telling it to run emacs itself. Codex wasn't able to reach feature parity though, like the background color indications (I supply a video in the readme). I didn't look too deep yet.

Reply on news.ycombinator.com