Progress on "Emacs for visualizing LÖVE apps": I h...
# devlog-together
k
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.
k
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.
b
One open question: supporting focus follows mouse. I don't know if it's possible in Emacs ...
sure it is, just customize
focus-follows-mouse
to
t
. Question is, what does "focus" mean for non-textual "windows" (=panes). But if your non-textual UIs still respond to kbd via a keymap->function, that part means same as in emacs.
> "every window is a scene and runs its own event loop" Do you mean actually separate process/thread, like a window system multiplexes display between processes? Or did you mean "you can think of it as event loop" but actually they all expose key-/event-maps and there is 1 central loop dispatching events to functions?
k
Yeah, just 1 central event loop doing the dispatching.
k
@Kartik Agaram Something you might want to look at for inspiration is StumpWM, an Emacs-inspired window manager for X11. I have been test-driving it for a while, and I expect to adopt it completely over the coming weeks, as my configuration improves. StumpWM implements "every window is a scene and runs its own event loop" by running an X11 application in every window.