Repository navigation
Improvements and Next Steps for the Processing Language Server (LSP) #1041
Description
Activity
the build is broken for the lsp server when i create a client and connect to the lsp server, the server does not compile, should i show the error logs here ?
Hi @Gmin2! Thanks for looking into it. Please do share the logs, thanks.
A quick note: with 4.4.0 and 4.4.1 the internal layout of the Processing app changed somewhat, breaking the
processing-javaCLI. The issue you're having might be related. We'll be releasing a fix in 4.4.3 tomorrow. Please use this PR instead in the meantime #1046cc @Stefterv
Also p.s. to keep this issue on topic, feel free to hop onto the
devs-chatchannel on the discord@Gmin2 You can use this link https://discord.gg/f9sCs2uY (note that it will expires in 7 days)
Reacted by Mintu GogoiThinking about this issue, I was really curious about whether it would be possible to integrate with Eclipse's LSP implementation, which is the foundation for VS Code's Java plugin. I did a quick proof of concept to demonstrate that this is possible:
Screen.Recording.2025-06-01.at.11.31.32.AM.mov
As you can see, basic things like syntax hi-lighting, completion, hover definitions, and go to definition in Processing's source all work out of the box, which is pretty cool!
How this works:
jdtlshas support for bare Java files and a concept called invisible projects, which basically creates a shadow project behind a single file. We add.pdeas a valid Java extension and intercept the call to produce the compilation unit, translate the Processing file to Java, and create a linked invisible project. We then have to do some annoying source mapping to translate the LSP commands, which are sent according to the original.pdepositions into positions in our Java file, but everything otherwise "just works."It's a bit flakey and I'm sure my source mapping logic is brittle and not particularly robust. But nice to validate that this is possible. If I were to go deeper here, I'd suggest speaking to some of the Eclipse devs themselves and seeing if they have any advice. The changes necessary to the core LSP classes was pretty minimal, but this is in general a difficult kind of thing to maintain through rebases. Ideally, we'd be able to sub-class some of their classes in our own JAR that we add to the classpath as a new entrypoint for the entire LSP process.
I also didn't give much consideration to how multi-file Processing projects would work, but presumably the invisible project pattern could handle them?
I still think that it may also be useful to point people who want to do editing outside of the PDE to just using regular Java, as the experience is likely to be better. Developing some kind of tooling that could convert a processing sketch into a Maven project could be a better approach overall.
Edit: Ran out of time to clean up the PoC and push but can later if there's interest.
To continue on @tychedelia's work, I'm testing right now if we can create a LSP proxy where we pre-process the pde file and then give the result to an existing Java LSP
I wanted to document how to setup the work with the LSP in Intellij IDEA:
- Install the LSP4IJ plugin in intellij
- I updated the
lsp-developtask in Gradle (might or might not be merged intomain) - Goto View->Language Servers
- Add a New Language Server
- Name: Processing Language Server
- Command: /path/processing-folder/gradlew -p /path/processing-folder lsp-develop run
- in the above its important to run both tasks as the first one reconfigures the second to work as a LSP
- Don't forget to set up the mappings so the LSP gets started when a Processing file is started
- Create a new run configuration for intellij with a Remote JVM Debug
- Port: 50006
- Listen to remote JVM
- Auto Restart (Yes)
- module classpath: processing
- Start the run configuration
- Put a debug point in
java/src/processing/mode/java/lsp/PdeLanguageServer.java's main function - Open a .pde file
- Happy debugging
Not sure if we want to improve this setup or make it more easily accessible in the future but at least there is a way to debug this way.
Okay I worked on the LSP proxy proof of concept today https://github.com/Stefterv/processing4/tree/lsp-proxy
Takeaways:
- I was successful in being a middle man in-between both the existing Processing LSP and for the Eclipse LSP, the existing LSP4J infrastructure came in very useful to deserialise and re-serialise the content being piped back and forth between the editor and the base lsp.
- I ran the PreprocessService as a middle step and I suspect that we can use the results of that as well to translate .java based suggestions into .pde based suggestions
Next steps:
- Demonstrate that we can easily translate suggestions from the eclipse.jdt LS to .pde suggestions
Reacted by Raphaël de Courville and charlotte 🌸
We’re revisiting the Processing Language Server with the goal of improving support for writing and editing Processing code outside the PDE.
Background
Several contributors have laid important groundwork for this effort:
pr05grant in 2024, @diyaayay worked on another VS Code extension though it did not make use of the built-in LSP.Proposed Improvements
We’d like to improve and extend the current functionality of the built-in LSP. Priorities are:
copy(sx, sy, sw, sh, dx, dy, dw, dh)) should show named parameterscolorMode(mode),colorMode(mode, max),colorMode(mode, max1, max2, max3))If you're interested in contributing or discussing further, feel free to comment here.
Thanks again to everyone who has contributed to this work so far!