Hey nice - this stuff is so much fun to me. I've worked a number of experiments like this too, especially related to live coding. Love seeing it in the wild.
I built a small project where you can live-code Love2D. The running program updates in real time (no saving needed) and see all values update in real-time, via LSP.
Here's another experiment where I made it so you could "drag and drop" to choose a position for something by manipulating the editor / replacing a computed position with a static one, on keypress.
I’ve been wanting to get into game programming and was looking at Love2D. I don’t know much Lua outside of what I’ve picked up with NeoVim configs.
This looks like it could be a great way to get my feet wet - I don’t do well with math and physics programming, but I used to make things in Flash back in the day that were similar to the particles demo and being able to quickly change things and see the updates makes it a lot easier for me to grok. Thanks for sharing!
This is close to the functionality that Borland Delphi had back in the 1990s. The pascal language and the design of their GUI toolkit were a really good impedance match, so you could freely switch between GUI design and editing the text version of it.
Doing so for languages like C++, was a sea of boilerplate that you couldn't touch, which is why I never moved away from Pascal. Similar fragility was evident in WxPython and it's builder.
I'm glad to see that LLMs can provide a match for less well suited Language/GUI pairs. We all deserve to get that kind of productivity.
For Slint [https://slint.dev], a (native) GUI Toolkit, I've also developed a LSP server that do live preview and editing.
You can try it online at https://slintpad.com : if you click on the toolbar button to enable the right panel, you can edit the properties from the UI, and this is all done through the LSP and can be integrated in any editor that supports it.
cool! how does this work? e.g. how do you know which UI element matches which text element, do you track it while rendering? How do you propagate changes in the UI? do you update the text and then re-render the whole UI?
I use the the code lenses of code action feature of the LSP so that the user can start a preview. The LSP server will then open a native window on desktop.
Every time the users do some change in the code, the editor sends the document and we re-render the preview.
I use the textDocument/documentHighlight request to know when elements are being selected from the code so I can highlight them in the preview.
When selecting an element in the preview UI, my LSP server sends a window/showDocument to position the cursor at the right location. And if the user changes property or do change in the file, we do a workspace/applyEdit command with the changes.
This is a great idea: I'd never think of using LSP for this!
As a software developer, I always get frustrated when I am doing some graphical work and struggle to neatly parametrize whatever I am drawing (wooden cabinets and furniture, room layouts, installation plans...) and switch between coding where that makes most sense and GUI where it doesn't.
The best I've gotten was FreeCAD with Python bindings (I've got a couple of small libraries to build out components for me), but while you can use your own editor, the experience is not very seamless.
And then I start imagining tools like the one here, but obviously doing it just right for me (balancing the level of coding or GUI work).
I think we’re a lot of developers who are frustrated by constantly needing to choose between code or GUI… both have their use case, but I feel like there must be a system that combines both.
How about a visual programming language? Plenty of 3D and CAD software uses a VPL for procedural design, which helps a ton to bring out the benefits of both
It's concerning to me that the LSP idea is .. a thing. Casey Muratori observed years ago that it's just a way worse way of doing libraries. Like, you're introducing HTTP where there could just be a function call into a DLL/SO. What's the benefit there? Just make vim/emacs/$editor speak some native protocol and be done with it. Then you GUI is just welded directly into the running editor process.. right??
There's no security risk there that wasn't present before as far as I can tell because you were already planning on running the LSP on your local machine..
I’ve definitely wondered about this. Like why does the language-understanding standard have to be a server specifically? Just cause it’s a good architecture to build around?
I think I’ve heard that vscode has benefitted hugely from it starting out with a client-server architecture from the start, since it started as a browser based editor. Things like editing code directly on servers via ssh or in containers is easy for vscode cause its client-server all the way down.
Vscode and LSP are both Microsoft products, maybe Microsoft has been pushing the client server thing?
> I’ve definitely wondered about this. Like why does the language-understanding standard have to be a server specifically?
I don't think it does. I think it's a bad architectural decision that web bros thought sounded cute.
> Things like editing code directly on servers via ssh or in containers
I mean, vim and emacs have supported editing over ssh for like .. longer than I've been alive probably.
> I think I’ve heard that vscode has benefitted hugely from [clinet-server architecture]
IMO VSCode is a giant steaming pile; I'm not sure what the huge benefits could have been. It's intolerably slow, uses an insane amount of system resources, and the debugger barely works most of the time.
IMO, many of these are marginal or nonce gains for the huge cost of introducing a network call in the middle of your program.
1. There's nothing stopping you from shoving the library code onto a thread. For something like this request-response style usage pattern, that sounds extremely straight-forward, especially since the previous paradigm was probably an async server anyways. The calling code (from the editor) obviously already had to be support async calls, so no real change there.
2. If $LANGUAGE can be used to write a server, it should be able to build a DLL. I realize this is not practically true, but I also don't support the notion that we should be writing even light systems stuff like this in JS or python.
3. lol. You're telling me you're worried about a process eating 32GB of ram parsing text files ..? If some core part of my editing workflow is crashing or running out of memory, it's going to be a disruptive enough event that my editor might as well just crash. The program I'm working on uses a lot of memory, my editor better not.
4. I guess ..? Barely seems like that's worth mentioning because .. counterpoint, debugging networked, multi-process programs is massively harder than debugging a singular process.
5. Why would I want (other than extremely niche applications, shadertoy comes to mind) an editor to run in a browser? If I have a browser, I can run an editor that connects to a remote machine. Furthermore, the `library-over-http` approach of LSPs doesn't really buy you anything in this scenario that using a single process wouldn't.. you can just send all the symbol information to the browser.. it's just not that big.
Isn’t the python based build123d the current best CAD in code solution? The problem with OpenSCAD is that it cannot export solid geometry, just a final mesh.
More broadly, I was genuinely shocked to realize, when I was playing with it, that there is no cross CAD file format that captures even simple design concepts like “this hole is aligned to the center of this plate” or even “this is a 2mm fillet”. STEP (the file format) mostly just captures final geometry.
I think CAD people just … redesign the part again if they need to move from say Fusion 360 to FreeCAD or whatever. How do they live like that?!
It's really hard to explain if you don't know how CAD kernels produce final BREP shapes via their process trees, but, try give an example-
something like "this is a 2mm fillet" requires a 'fillet solver' that is deeply ingrained in the kernel. It isn't something that would ever be portable, say, from Fusion360 to CATIA natively because those are completely different kernels with different ways of 'solving' the model (and not just fillets, but, everything).
That is why STEP containing the final BREP manifold solid is the standard interchange that it is - it is a final representation of the solved output that IS portable, and anything else is... difficult.
This is helpful but surely we can save a consistent description of the process step and the input parameters alongside the final geometry in the same file format?
STEP is capable of capturing what you describe, it is down to the "user group" of customers of the CAD vendors to ask for it to be implemented by each CAD system in terms of what they import and export.
We put in for some funding for the next edition of STEP AP242 for me to be able to work more closely with the user group to improve this area.
That's awesome! Yeah it seems strange to me that we don't have a standard way of tracking how a model is built up and parameterized (basically Fusion 360's history mode). I'd naively assumed that this was a solved problem in the CAD world - given the whole point of parametric CAD is to be able to easily tweak the distance between two points and have the whole model update.
The interoperability problem stems from CAD kernels using proprietary B-rep representations and constraint solvers, with STEP's AP242 standard attempting to address this by including Product Manufacturing Information (PMI) and semantic annotations, though adoption remains fragmented.
But given how many companies need to work with diverse suppliers, there must be a whole bunch of re-creating models happening. There is no chance that everybody is using the same CAD tool
It is referenced down in the wonderful tree of knowledge, but I thought I would lift this info up to the top level. A system like this called a "bimodal editor" from the work of Ravi Chugh [1] see the project Sketch-n-Sketch [2] these kinds of systems got a big kick in the pants with Bret Victor's talk Inventing On Principle [3]. That in turn kicked off a wonderful dynamic execution Clojure IDE called lighttable [4]
There are tons of other great research projects and researchers in this fascinating space. Comment is not meant to exclude.
Readit News
I built a small project where you can live-code Love2D. The running program updates in real time (no saving needed) and see all values update in real-time, via LSP.
https://github.com/jasonjmcghee/livelove
And also added the same kind of interactivity like a number slider and color picker that replace text inline, like yours (though via vs code extension: https://gist.github.com/jasonjmcghee/17a404bbf15918fda29cf69...)
Here's another experiment where I made it so you could "drag and drop" to choose a position for something by manipulating the editor / replacing a computed position with a static one, on keypress.
https://clj.social/@jason/113550406525463981
There's so much cool stuff you can do here.
This looks like it could be a great way to get my feet wet - I don’t do well with math and physics programming, but I used to make things in Flash back in the day that were similar to the particles demo and being able to quickly change things and see the updates makes it a lot easier for me to grok. Thanks for sharing!
Highly recommend adding code definitions https://github.com/LuaCATS/love2d
And getting the lua LSP.
It reminds me a lot of processing / p5js. So easy to get something fun up and running quickly.
Deleted Comment
Doing so for languages like C++, was a sea of boilerplate that you couldn't touch, which is why I never moved away from Pascal. Similar fragility was evident in WxPython and it's builder.
I'm glad to see that LLMs can provide a match for less well suited Language/GUI pairs. We all deserve to get that kind of productivity.
Every time the users do some change in the code, the editor sends the document and we re-render the preview.
I use the textDocument/documentHighlight request to know when elements are being selected from the code so I can highlight them in the preview.
When selecting an element in the preview UI, my LSP server sends a window/showDocument to position the cursor at the right location. And if the user changes property or do change in the file, we do a workspace/applyEdit command with the changes.
Btw, the code is there: https://github.com/slint-ui/slint/tree/master/tools/lsp
As a software developer, I always get frustrated when I am doing some graphical work and struggle to neatly parametrize whatever I am drawing (wooden cabinets and furniture, room layouts, installation plans...) and switch between coding where that makes most sense and GUI where it doesn't.
The best I've gotten was FreeCAD with Python bindings (I've got a couple of small libraries to build out components for me), but while you can use your own editor, the experience is not very seamless.
And then I start imagining tools like the one here, but obviously doing it just right for me (balancing the level of coding or GUI work).
There's no security risk there that wasn't present before as far as I can tell because you were already planning on running the LSP on your local machine..
I think I’ve heard that vscode has benefitted hugely from it starting out with a client-server architecture from the start, since it started as a browser based editor. Things like editing code directly on servers via ssh or in containers is easy for vscode cause its client-server all the way down.
Vscode and LSP are both Microsoft products, maybe Microsoft has been pushing the client server thing?
I don't think it does. I think it's a bad architectural decision that web bros thought sounded cute.
> Things like editing code directly on servers via ssh or in containers
I mean, vim and emacs have supported editing over ssh for like .. longer than I've been alive probably.
> I think I’ve heard that vscode has benefitted hugely from [clinet-server architecture]
IMO VSCode is a giant steaming pile; I'm not sure what the huge benefits could have been. It's intolerably slow, uses an insane amount of system resources, and the debugger barely works most of the time.
1. naturally async
2. each server and the editor itself can be written in its own language and runtime easily
3. servers can just crash or be killed because of oom errors and your editor won't be affected
4. in a lot of languages it is easier to write a server then to call/export c abi
5. the editor can run in a browser and connect to a remote server
6. you can have a remote central server
all of those things are done in practice
1. There's nothing stopping you from shoving the library code onto a thread. For something like this request-response style usage pattern, that sounds extremely straight-forward, especially since the previous paradigm was probably an async server anyways. The calling code (from the editor) obviously already had to be support async calls, so no real change there.
2. If $LANGUAGE can be used to write a server, it should be able to build a DLL. I realize this is not practically true, but I also don't support the notion that we should be writing even light systems stuff like this in JS or python.
3. lol. You're telling me you're worried about a process eating 32GB of ram parsing text files ..? If some core part of my editing workflow is crashing or running out of memory, it's going to be a disruptive enough event that my editor might as well just crash. The program I'm working on uses a lot of memory, my editor better not.
4. I guess ..? Barely seems like that's worth mentioning because .. counterpoint, debugging networked, multi-process programs is massively harder than debugging a singular process.
5. Why would I want (other than extremely niche applications, shadertoy comes to mind) an editor to run in a browser? If I have a browser, I can run an editor that connects to a remote machine. Furthermore, the `library-over-http` approach of LSPs doesn't really buy you anything in this scenario that using a single process wouldn't.. you can just send all the symbol information to the browser.. it's just not that big.
6. Wut?
More broadly, I was genuinely shocked to realize, when I was playing with it, that there is no cross CAD file format that captures even simple design concepts like “this hole is aligned to the center of this plate” or even “this is a 2mm fillet”. STEP (the file format) mostly just captures final geometry.
I think CAD people just … redesign the part again if they need to move from say Fusion 360 to FreeCAD or whatever. How do they live like that?!
That is why STEP containing the final BREP manifold solid is the standard interchange that it is - it is a final representation of the solved output that IS portable, and anything else is... difficult.
We put in for some funding for the next edition of STEP AP242 for me to be able to work more closely with the user group to improve this area.
Of course it’s great for vendor lock-in.
But given how many companies need to work with diverse suppliers, there must be a whole bunch of re-creating models happening. There is no chance that everybody is using the same CAD tool
Screenshots and GIFs for the explanation!
https://github.com/williamcotton/guish
There are tons of other great research projects and researchers in this fascinating space. Comment is not meant to exclude.
[1] https://people.cs.uchicago.edu/%7Erchugh/
[2] https://ravichugh.github.io/sketch-n-sketch/
[3] https://vimeo.com/906418692
[4] https://web.archive.org/web/20250616031034/http://lighttable... (demo video plays)