There are too many ways to toggle diagnostics

Why is there 3 different ways to disable diagnostics?

The Problem

Currently, there is:

• Lua.diagnostics.disable
  • An array of strings where you specify each diagnostic to disable
  • Simple, but has no control for open/closed files
• Lua.diagnostics.neededFileStatus
  • An object where the key is the name of the diagnostic and the value is how the diagnostic will be checked (not at all, only open files, all files)
  • Slow but precise, allows you to alter the most diagnostics but can be slow to get everything set up the way you like it. Good for long-term setup where you can get set up perfectly.
• Lua.diagnostics.groupFileStatus
  • An object where the key is the name of the group and the value is how the group of diagnostics will be checked (not at all, only open files, all files)
  • Quick but not precise, allows the user to quickly turn off entire categories of diagnostics but does not allow for disabling individual diagnostics. Good for short-term setup.

This can get very confusing very quickly.

The solution

I think going with just Lua.diagnostics.neededFileStatus would make the most sense.

It allows for the user to completely customize how the server runs, which is more important than the user quickly being able to get things working sort of how they like it in the short-term.

To still help get users up and running as fast as possible, we can offer "presets" or "popular configs" on the discussions page. This can help satisfy those that want just the basics or full strict mode.

This would definitely be a breaking change but I think it is a very important one to make!

Originally posted by @carsakiller in https://github.com/sumneko/lua-language-server/discussions/1362#discussioncomment-3194851

Beginne damit, die Implementierungen und die Konfigurationsdokumentation für Lua.diagnostics.disable, Lua.diagnostics.neededFileStatus und Lua.diagnostics.groupFileStatus zu finden. Ermittle den Umfang der Breaking Changes und wie Presets oder gängige Konfigurationen die entfernten Optionen ersetzen könnten; die Arbeit ist abgeschlossen, wenn ein konsistenter Konfigurationsweg dokumentiert und unterstützt wird.