Please allow users to easily configure sensitivity to errors/warnings (squiggles)

Users are annoyed and distracted by a variety of error and warning indicators. (i.e. "the squiggle obfuscates the code when it applies to an entire block of code")

It's not an isolated complaint (see similar issue 1657). #1657

---------------------------------- Suggested remedies ------------------------------------------------------------------------------------------------ -
Could the yellow squiggly for warnings be removed or have the option to turn them on or off within the workspace plugin settings?

Maybe show a warning marker on the line number instead (or another option to turn on or off if people want yellow squiggly and marker on the line number)?

Or is there a lever / option to change the color of the squiggly in the workspace? Maybe make it more transparent? Possibly a theme option/setting?

Please consider these ideas, look for ways to make the Java extension even better. Thank you.

Currently, I don't think there's a nice to way to set this since there's so many possible options, and I don't think we have a UI to go through all of them, but it should be possible to configure.

For example, in a Maven project, I ensured there was a .settings/org.eclipse.jdt.core.prefs file. This file has a key=value format and the various options can be found at https://github.com/eclipse/eclipse.jdt.core/blob/master/org.eclipse.jdt.core/model/org/eclipse/jdt/core/JavaCore.java#L270 (listing the key, possible values, and the default).

We do override some of these defaults in https://github.com/eclipse/eclipse.jdt.ls/blob/master/org.eclipse.jdt.ls.core/src/org/eclipse/jdt/ls/core/internal/preferences/PreferenceManager.java#L124 .

So it is possible to customize these options. With that said, do you have a rough idea of which errors/warnings are particularly annoying ? Maybe we could consider changing their default state.

@rgrunber

Hi @rgrunber ,
Thanks for the above note.
We do not have a list of which messages are targeted. Maybe it would be best to start with the ability to turn off WARNs, we can further refine if we get more feedback.

@fbricon

@fbricon , @testforstephen here's an example of a case where a global settings file would be beneficial. Also, some kind of location that lists the available options as opposed to having to reference the source javadoc.

I have a small draft of such a feature I can post soon. It works as follows. For every error/warning message that can actually be ignored, a code action is generated called "Ignore ${message}" . If performed, it will create/append a file under .settings/org.eclipse.jdt.core.prefs of the project with an entry to ignore that particular error/warning. A few things still to address :

If an element has something like 3 warnings, that's 3 different code actions, and this dynamic behaviour could produce some ugly menu popups if the number grows. Maybe have an option like "Ignore all errors/warnings for element" when more than 3 errors/warnings ? If a user still wanted to only disable a particular one, they would still be able to remove the unwanted ones from the settings file. Entry names are pretty intuitive.
Currently the options to ignore are saved to the project specific settings file, but we could potentially save to the global one. My preference is for the project file for now.
Noticed some odd behaviour in appending/creating the project settings file, where occasionally the options aren't respect. This seems to point more to some issues we may have with responding to changes in the settings file.

Generate code action to ignore certain compiler issues.

If an element has something like 3 warnings, that's 3 different code actions, and this dynamic behaviour could produce some ugly menu popups if the number grows. Maybe have an option like "Ignore all errors/warnings for element" when more than 3 errors/warnings ? If a user still wanted to only disable a particular one, they would still be able to remove the unwanted ones from the settings file. Entry names are pretty intuitive.

The label is Ignore compiler problem(s) and it will ignore all compiler problems annotated on the current line.

Currently the options to ignore are saved to the project specific settings file, but we could potentially save to the global one. My preference is for the project file for now.

It now respects java.settings.url and will save the options there. If that setting is not defined / file doesn't exist, then the setting will be saved to the project metadata location (it applies the option for every Java project imported). A simple Java: Clean Java Language Server Workspace can be used to clear these out.

Noticed some odd behaviour in appending/creating the project settings file, where occasionally the options aren't respect. This seems to point more to some issues we may have with responding to changes in the settings file.

Found the problem. We're sending a regular string absolute path as a glob pattern for the watcher registration. This ends up calling VS Code's workspace.createFileSystemWatcher(..) which states :

* Providing a string as globPattern acts as convenience method for watching file events in
* all opened workspace folders. It cannot be used to add more folders for file watching, nor will
* it report any file events from folders that are not part of the opened workspace folders.

So we need to use https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#relativePattern to listen for files that may exist outside the workspace. I have a fix for this but I'll address it in ~~a separate~~ the same PR.

Generate code action to ignore certain compiler issues.

Hi, java.settings.url is working correctly if the file already exists in the filesystem, but not if the file doesn't exist. I don't know if this is a bug, but anyway could be added the possibility to create automatically the file if "java.settings.url" is set?

Navigation Menu

Repository navigation

Please allow users to easily configure sensitivity to errors/warnings (squiggles) #1791

4 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Please allow users to easily configure sensitivity to errors/warnings (squiggles) #1791

Description

Activity

rgrunber commented on Feb 4, 2021

RickJWagner commented on Feb 23, 2021

rgrunber commented on Mar 31, 2021

rgrunber commented on May 5, 2021

4 remaining items

rgrunber commented on Mar 6, 2025

antony84 commented on May 24, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions