d12frosted

8 ms·

1. 1.▲
   by d12frosted 8mo ago

   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 para
2. 2.▲
   by d12frosted 8mo ago

   Thanks for the detailed breakdown on Pathom and cljfx subscriptions - this is exactly the kind of perspective I was hoping to hear. The resolver model you describe (dumb functions, map-in → map-out, parallelizable) is appealing. It's s
3. 3.▲
   by d12frosted 8mo ago

   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 fo
4. 4.▲
   by d12frosted 8mo ago

   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 signi
5. 5.▲
   by d12frosted 8mo ago

   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 general
6. 6.▲
   by d12frosted 8mo ago

   vui-table supports three :border variants at the moment - :ascii, :unicode and nil (i.e. none) :ascii +---------+--------+ | Summary | | +---------+--------+ | RMS | 4.1620 | | AVG | 3.9558 | +---------+--------
7. 7.▲
   by d12frosted 8mo ago

   Good points, thanks for engaging thoughtfully. On vui.el's approach - yes, the blessing is that widget.el is simple enough to build on. It does the "rendering" and some "behaviour", vui.el handles the rest. On ECS v
8. 8.▲
   by d12frosted 8mo ago

   Interesting, thanks for sharing! I've had thoughts about making vui.el backend-agnostic so it could target different widget implementations (like xwidgets or even native-GUI). An SDL-based widget library could potentially be one of tho
9. 9.▲
   by d12frosted 8mo ago

   Good point. Though for widget UIs you're typically rendering structured data you control, not parsing arbitrary text files. The syntax highlighting / validation concern applies to editing code, not to building interactive interfac
10. 10.▲
    by d12frosted 8mo ago

    The long-line issue is real, though my statement was specifically about building UIs with widgets/overlays/text properties - not handling arbitrary files. In that context, Emacs's display engine is genuinely well-optimized: i
11. 11.▲
    by d12frosted 8mo ago

    sorry for that! added a dark theme, feedback is welcome :pray:
12. 12.▲
    by d12frosted 8mo ago

    easy :) ask for dark theme; will try to implement one soon ;) update: added; turns out I almost finished it before on a local branch but didn't push to master