Improvements and Next Steps for the Processing Language Server (LSP)

[SableRaf]

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 pr05 grant 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!

[Gmin2]

Hey @SableRaf would love to work on Displaying parameters name in the function signatures functionality, i can go ahead with it right?

[SableRaf]

Hi @Gmin2! Nice to hear from you 😃 Sure, if you'd like to make a PR, we'll be happy to review it.

[Gmin2]

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]

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-java CLI. 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 #1046

cc @Stefterv

[Stefterv]

I don't think this has anything to do with the processing cli @SableRaf

@Gmin2 are you building using Ant or Gradle?

[Stefterv]

Also p.s. to keep this issue on topic, feel free to hop onto the devs-chat channel on the discord

[Gmin2]

@Gmin2 are you building using Ant or Gradle?

i am using gradle
could yu share the discord link @Stefterv

[SableRaf]

@Gmin2 You can use this link https://discord.gg/f9sCs2uY (note that it will expires in 7 days)

[Stefterv]

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]

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: jdtls has support for bare Java files and a concept called invisible projects, which basically creates a shadow project behind a single file. We add .pde as 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 .pde positions 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]

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:

1. Install the LSP4IJ plugin in intellij
2. I updated the lsp-develop task in Gradle (might or might not be merged into main)
3. Goto View->Language Servers
4. 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
5. Create a new run configuration for intellij with a Remote JVM Debug
   • Port: 50006
   • Listen to remote JVM
   • Auto Restart (Yes)
   • module classpath: processing
6. Start the run configuration
7. Put a debug point in java/src/processing/mode/java/lsp/PdeLanguageServer.java's main function
8. Open a .pde file
9. 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.

[Stefterv]

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