How to properly set excludedMarkerTypes / what's the correct value

[Bnaya]

I'm doing some code analysis using the lang server Some of the projects are intentionally not complete, without the deps and all. And I'm getting tons of this kind of diagnostics that i would like to ignore.

{
  "uri": "%DIR%elasticsearch/server/src/main/java/module-info.java",
  "diagnostics": [
    {
      "range": {
        "start": {
          "line": 20,
          "character": 13
        },
        "end": {
          "line": 20,
          "character": 34
        }
      },
      "severity": 1,
      "code": "8389908",
      "source": "Java",
      "message": "org.elasticsearch.cli cannot be resolved to a module"
    },

I've trying sending the following excludedMarkerTypes but it's not working excludedMarkerTypes: ['org.eclipse.lsp4j.Diagnostic', 'org.eclipse.lsp4j.diagnostic', 'org.eclipse.lsp4e.diagnostic'], I'm probably doing something wrong. How can i determining the correct marker type to ignore diagnostics?

[rgrunber]

Couldn't you ignore the markers/diagnostics on the client side ?

the excludeMarkerTypes is unfortunately not that granular. The "type" often refers to the marker contributor so very often many different kinds of markers are contributed under one type. For example, all of the errors reported by JDT are under org.eclipse.jdt.core.problem.

An example of how it's used :

https://github.com/eclipse-jdtls/eclipse.jdt.ls/blob/27a1a1e1f6e1b598b5d9cb5ef00b3783b7ee458a/org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/handlers/BaseDiagnosticsHandler.java#L159-L165

Where a marker's type is a subtype of another type if the marker's extension point definition contains that type : https://github.com/eclipse-jdt/eclipse.jdt.core/blob/c1875a13ec830b248cf5a16b9d8ca16c53d811a6/org.eclipse.jdt.core/plugin.xml#L115-L123

[Bnaya]

Thank you!

I want to reduce the noise sent to my client basically I don't want diagnostics at all, i don't mind to to filter "too wide" Adding org.eclipse.jdt.core.problem to the excludedMarkerTypes didn't help.

I'm still not sure how can I deduct the right marker type

[rgrunber]

Currently, I don't see a nice way for the client to disable diagnostics completely. In fact if you look at the code I referenced above we even prevent adding the org.eclipse.jdt.core.problem to excluded markers by checking ahead if it's that type and skipping the filtering :neutral_face: ( return !marker.isSubtypeOf(IJavaModelMarker.JAVA_MODEL_PROBLEM_MARKER) && ... )

Part of the problem is outlined in https://github.com/eclipse-jdtls/eclipse.jdt.ls/issues/2422 . We use textDocument/publishDiagnostics which is a notification from server to client. In other words, we're currently sending diagnostics to the client without even a request.

In more recent versions of the LSP, there was support added for clients to more easily configure when diagnostics are requested, so once that issue is resolved, you should have better support.

Let's consider this as raising the priority on looking at #2422. We could also modify excludeMarkerTypes to take in some kind of regex but that issue seems like the right approach.

[fbricon]

@Bnaya wouldn't running jdt.ls in syntax server mode be enough for you (only syntax errors are reported, but no classpath computation) ?

[Bnaya]

@Bnaya wouldn't running jdt.ls in syntax server mode be enough for you (only syntax errors are reported, but no classpath computation) ?

I have tried, but it doesn't not give me the features I need

Some background: I'm doing some automatic code analysis using the LSP (multiple langs using other servers) I don't need the project to be complete or buildable, but i do need it do find references between files etc, but not dependencies (for now)

So I'm disabling gradle and maven, and my project is full with errors, that i don't really care about. And basically for each file I open i get huge list of diagnostics that spam my LSP trace log. I would even prefer to be able to tell the server to do "less work" and not only not send, but not look for these kind of issues

Thank you for the detailed answers!