Comment by whacked_new | Hacker News Reader

Comment by whacked_new | Hacker News Reader

Parent Full thread

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