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.