Kartik Agaram 2025-01-07 00:22:08 Progress on "Emacs for visualizing LÖVE apps": I have the first message between windows. I press a key, the key gets processed by the first window's keymap and dispatched to a function, which reads the selection, parses it and sends a message to the second window. The second window then responds to the message by adding a new object into its scene.
In principle, this approach feels nice and timeless. I think "every window is a scene and runs its own event loop" is more general a foundation than Emacs's "every window is a buffer containing text." It feels realistic to provide this foundation alongside a wide library of primitives for text rendering and analysis.
In practice, I've been struggling to find a focus, and I'm probably going to focus on creating tools for myself to more visually debug the LÖVE apps I create. I'm not going to focus at the moment on:
- editing the source code for the environment in the environment, the way you can modify Emacs sources from within Emacs. I already have a way to do that: you open a second window and modify the app live as it runs.
- interfacing with other processes or tools besides LÖVE, the way Emacs lets you connect to any programming language REPL.
Both these are totally feasible. I don't think any crucial infrastructure is missing here. They're just not priorities for me right now. I plan to focus on more easily adding new windows to a LÖVE app, and creating new kinds of debug UIs in them.
One open question: supporting focus follows mouse. I don't know if it's possible in Emacs, and even if not I think it makes a lot more sense in a more graphics- and mouse-centered environment. Again, not a priority but perhaps this is a sign this foundation is not quite as timeless as I would like.
Konrad Hinsen 2025-01-07 06:56:13 Nice!
I suspect that focussing on your own immediate needs is the only way to make good tools that are not simply clones of mainstream things. And I doubt there is much value in making an Emacs clone in LÖVE. You'd be eternally trying to catch up with Emacs' 40 years of advance.
Kartik Agaram 2025-01-11 06:32:23 The kids have been playing with a pen on a pendulum, I don't know what the technical term is for it, but that didn't stop me from playing with it. This way I can adjust the friction.
Tom Larkworthy 2025-01-12 13:24:14 I think there is a shortcut to direct manipulation by "inverting" grammar of graphics.
Ivan Reese 2025-01-12 21:28:12 What is "the grammar of graphics"? What do you mean by that?
For me, a graphic is a drawing. I can create it with code, but I usually create it with something a little more… pen-like (digital or analog).
I suspect you're referring to "graphic generated by code[+data]".
Tom Larkworthy 2025-01-13 08:34:14 Sorry, yeah, curse-of-knowledge. "the grammar of graphics" is the foundation of various plotting libraries (e.g. ggplot). This technique. To decompose a technical drawing into a few orthogonal pieces, most importantly to this work is a "scale". A scale maps data space to pixel space. Its a great abstraction, as it supports categorical and non-linear projections (e.g. a world map). To draw dots on a map you just define a scale that maps lat-long to a spherical coordinate system embedded on a plane (the plane literally being the computer screen), although your library probably already does it. This is a fairly entrenched abstraction at this point in data viz. Scales are 1st class in Plot, vega-lite or ggplot
My contribution is you can take the inverse of scales as they are quire well founded mathematically. The inverse is pixel space to data space, then, mouse movement in pixel space can be translated to movement in data space. And thats defines quite a large number of interactive diagrams. So with this procedure take any visualization library, figure out how to inverse the scales it supports, and now you get create new interactive widgets by customizing how the control surfaces are represented visually.
Since those first two I have managed to create slider arrays and a graph editor. My code is about 40 LoC, all the heavy lifting is done by the visualization library, those 40 LoC are powering all the different flavours of UI editors.
