You have to tell the server how to interpret the code somehow. I mentioned line length. In Python, you may want one configurable max for code and another for comments. If you can pass those to the server, it can tell you which lines are too long using the standard mechanism for identifying errors and warnings. Otherwise, the editor would have to know how to parse the code so it could know whether a given line is code or comment. That’s the sort of thing LSP can do better.
That’s just one example, not the lone thing users would likely configure.
I get what you are saying, but it still sounds like a linter. And the linter (and syntax highlighting etc.) do need to understand the code - but the LSP is not necessarily the right tool for that.
In many cases the right tool is something like treesitter. Treesitter paired with an LSP is an incredible combination.
But yes, I understand your frustration. And if the best implementation happens to be inside the LSP then so be it.
I see your point, too. (And also adore treesitter!)
The examples I gave were around lint-y types of things, but the same problem affects more LSP-y things, too. The link I gave has lots of tweakable knobs for refactoring plugins and other stuff that’s more philosophically in-scope for language servers.
That’s just one example, not the lone thing users would likely configure.
Edit: More concretely, here are some of the config knobs you can twiddle via LSP for the particular server I’ve been discussing: https://github.com/python-lsp/python-lsp-server/blob/develop...
There are other plugins around with settings that aren’t documented there, but are still configured through the same mechanism.