Repository navigation
Improvements and Next Steps for the Processing Language Server (LSP) #1041
Description
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:
- Initial work by @kgtkr was incorporated for Processing 4.1. They also built a minimal Processing LSP client for VSCode.
- Further work by @Efratror was included in Processing 4.3 (see [PR] LSP feature/declaration support - [merged] #678 and [PR] Lsp feature/reference support - [merged] #690)
- As part of the
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:
- Display parameter names in function signatures (e.g.,
copy(sx, sy, sw, sh, dx, dy, dw, dh)) should show named parameters - "Go to declaration" for built-in functions and classes (linking to Processing source code when possible)
- Hover documentation for built-in functions and core classes
- Support for overloaded functions (e.g.,
colorMode(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!
Reacted by Stef Tervelde, kgtkr, Diya Solanki, rajat khanduri, Moon and charlotte 🌸
Activity
Gmin2 commentedon Apr 16, 2025
Hey @SableRaf would love to work on Displaying parameters name in the function signatures functionality, i can go ahead with it right?
SableRaf commentedon Apr 16, 2025
Hi @Gmin2! Nice to hear from you 😃 Sure, if you'd like to make a PR, we'll be happy to review it.
Gmin2 commentedon Apr 24, 2025
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 ?
SableRaf commentedon Apr 24, 2025
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
Stefterv commentedon Apr 24, 2025
I don't think this has anything to do with the processing cli @SableRaf
@Gmin2 are you building using Ant or Gradle?
Stefterv commentedon Apr 24, 2025
Also p.s. to keep this issue on topic, feel free to hop onto the
devs-chatchannel on the discordGmin2 commentedon Apr 24, 2025
i am using gradle
could yu share the discord link @Stefterv
SableRaf commentedon Apr 24, 2025
@Gmin2 You can use this link https://discord.gg/f9sCs2uY (note that it will expires in 7 days)
Stefterv commentedon Apr 24, 2025
I've added #1059 to help aid in the development of the LSP, if anyone has suggestions or ideas on how to improve, let me know!
tychedelia commentedon Jun 1, 2025
Thinking 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.
Stefterv commentedon Sep 9, 2025
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:
lsp-developtask in Gradle (might or might not be merged intomain)java/src/processing/mode/java/lsp/PdeLanguageServer.java's main functionNot 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.
Stefterv commentedon Sep 10, 2025
Okay I worked on the LSP proxy proof of concept today https://github.com/Stefterv/processing4/tree/lsp-proxy
Takeaways:
Next steps: