Comment by kstrauser | Hacker News Reader

Comment by kstrauser | Hacker News Reader

I’m fighting with it right now. LSP specifies several configuration mechanisms but there isn’t a “blessed” one. This is a pain point because:

I want to write Python.

There’s one FOSS language server (pylsp) that’s a better fit for my needs than the other Python servers.

I want to use a certain commercial editor.

The editor and the language server don’t share a common configuration method.

Ergo, I can’t use the editor I’d like to write Python the way I want. It’s no one’s fault. The editor works just fine with other servers, for Python and for lots of other languages. The server is also operating within spec, and plenty of editors support its configuration method. However, they don’t play well with each other. I can still use the editor with that server as long as I’m ok with the default settings, but I’m not.

It would’ve been spiffy to have a preferred baseline method that all editors and language servers spoke, but they went the enterprisey “here are a hundred options - pick a few!” overly configurable direction.

Bummer. I really, really like that editor.

Have you opened an issue against https://github.com/python-lsp/python-lsp-server? I'm an occasional contributor for easy fixes; if your fix is easy chances are it would get picked up.

I came in at the tail end of https://github.com/python-lsp/python-lsp-server/issues/195. The possibility of me sponsoring a fix came up, and I’m on board with it, but the other contributor never replied.

Ah yeah, Carlos is very low on cycles (like all of us I guess), probably due to the day job. (If only OSS had competitive pay...)

That happens. I’m kind of bummed at the situation in general, but no one owes me to prioritize my convenience over theirs.

Perhaps unrelated but Ive been meaning to ask and I couldn't find - what's the deal with python-lsp-server and virtualenvs? It seems like it has to be installed in the virtualenv to provide completions, etc. Is that right?

No. The editor sends information about the environment to the server. That was a mystery to me, too, for a while.

What is configuration in this case?

In this specific case, enabling specific plugins, configuring their behavior, adjusting maximum line lengths, that sort of thing.

That seems out of scope of what LSP deals with

That’s exactly the kind of thing LSP deals with. You have to get those settings into the server somehow, and the main methods are for the editor to send them to the server, or for the server to load them from somewhere in the filesystem or similar. A lot of those settings (like line length) are configured in the editor by the user. It makes a lot more sense to have a mechanism to communicate them over the same protocol than to use a janky method like writing to a file with a specific name, or some other out-of-band method.

LSP assumes that there is a higher level editor integration that handles configuration. That’s not ideal but it’s somewhat sensible as different editors will want to expose different ways to configure them.

True, but there are also a slew of methods like workspace/didChangeConfiguration for passing config around in-band.

Ideally, adding an LSP would just be adding a file path to your editor config. This file could contain standard info like supported file extensions, the executable of the LSP, and the parameters to pass the executable. You could also disable/ignore certain features. And, this file would have a common format across all IDEs.

LSP is a protocol for answering queries about the language model behind the text, not controlling anything about the text itself (expect for auto formatting, but that's a bit special). Those configurations seem to be in scope for the text editor, not the language server.

In fact LSP is mostly configuration agnostic. It might use configuration for a particular query like autoformatting, but it's still request/response in terms of text edits.

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.

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.

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.

This is incorrect;

The textDocument/diagnostic[1] is far beyond "the language model behind the text" and includes linting which many LSP servers implement (TS and python for example), and it can also happen as a "push" as opposed to "request/response"

[1]: https://microsoft.github.io/language-server-protocol/specifi...

No, LSP describes what information to present in the editor. For example, Inlay Hints. The user might want to see the type of every inferred variable, or just inferred return types of functions, or nothing at all. LSP needs to consider the user config and only send the info that should be displayed.

> LSP is a protocol for answering queries about the language model behind the text, not controlling anything about the text itself (expect for auto formatting, but that's a bit special)

LSP supports refactoring with "Code Action Request":

https://microsoft.github.io/language-server-protocol/specifi...

That's more than simply answering queries about the model.

people actually like their editor? blasphemy. you must be using either sublime or kakoune

supreme blasphemy. Emacs

you just have a call to (stockholm-syndrome) buried somewhere in your 1200 line init file

(xkcd-get 297)

https://xkcd.com/297/

https://github.com/vibhavp/emacs-xkcd

Parenthesis are flying like god's edition… ;D

The amount of Emacs configuration I had was what drove me to the insanity of writing my own editor....

I do! The one here is BBEdit which you can extend by writing - ready for this? - command line programs. It didn’t come with a built-in JavaScript formatted, so I wrote a shell script that runs Prettier on its input, and told BBEdit to run that script when I hit F1. Voila. JavaScript formatting. It’s also incredibly fast and responsive.

If I can’t get it working to write Python the way I want, I’m going back to Emacs. It’s not a “native” Mac app, but doesn’t fall into the uncanny valley the way things like VSCode do.

I've been down that path with both Acme and Kakoune, although I went with separate formatting scripts based on whatever seemed to work best for each language. But I started to go a little insane trying to extend those editors, because I realized that I hate working with the shell and prefer to avoid working with it at all cost. And so back to Emacs I went. And now I oscillate between repeatedly poking my config with a stick, and trying to force myself to migrate to VS Code.

I switched from Emacs to VSCode for a while, but couldn’t stick with it. It’s soooo easy to set up and start using, and it does the right thing 99% of the time. However, that 1% drove me nuts. I don’t remember the specifics, just that there were a few things that bugged the everliving hell out of me, and they couldn’t be changed without doing some significant work inside VSCode itself and then in its extensions.

The worst thing about Emacs is how it absolutely spoils everything else. Yes, it’s a pain in the neck at times, but you can change anything you want.

That said, BBEdit got far closer to my platonic ideal editor than VSCode ever did, and it’s nice enough in other ways to win me over.

Haha, yes, virtually all of that has been my experience as well, except substituting BBEdit for Sublime. I'm still convinced that just sucking it up and sticking with VS Code is the way to go, I just can't make it stick.

But Emacs is still alluring enough that I spent like 4 hours over the last few days trying to get clangd to work in a project that involves cross compiling C++ in a way where generating compile_commands.json does not seem possible, with no success, even with the help of clangd contributors, where VS code somehow is able to just work with minimal configuration of the C/C++ extension. Someday I will stop doing this to myself, hopefully.

My yesterday looked a lot like that. Well, if I can't get BBEdit to work like I'd like, guess it's time to dust off my Emacs config and modernize it. Once more into the breach!

If you figure out how to stop this, please let me know.

Reply on news.ycombinator.com