Feature request: convenient way for users to set config generically

[michaelpj]

We have defcustom-lsp, which is great. However, it has two problems:

1. The server can be ahead of the client. This is pretty common: I'm not reactive enough to add new defcustom-lsps to the client as soon as they're available in the server. So then users can't set those options easily.
2. The server can be behind the client. This is less common, but potentially problematic. If I do add new options to the client, but someone is using an old server with different options, they can have problems.

It would be nice if there was a convenient way to set "generic" config options for a server. Maybe there already is, and it just needs to be documented, but ultimately they just need a way to set key-value options for a server.

That would solve both problems: users can set the options that they know make sense for the server they're using, even if our client code doesn't expose them nicely.

[yyoncho]

The server can be ahead of the client. This is pretty common: I'm not reactive enough to add new defcustom-lsps to the client as soon as they're available in the server. So then users can't set those options easily.

That works:

(lsp-register-custom-settings '(("key" "literal-value")))

It would be nice if there was a convenient way to set "generic" config options for a server. Maybe there already is, and it just needs to be documented, but ultimately they just need a way to set key-value options for a server.

That is a request against lsp protocol. It was suggested in the past but I am not sure what was the outcome.

[michaelpj]

That works:

Okay, then maybe this is just a documentation request. I can try and put something together.

That is a request against lsp protocol. It was suggested in the past but I am not sure what was the outcome.

I think I'm mis-communicating: I don't want to set options that the server doesn't understand, I just want to be able to let the user easily shove in whatever configuration they happen to know makes sense.

[yyoncho]

I think I'm mis-communicating: I don't want to set options that the server doesn't understand, I just want to be able to let the user easily shove in whatever configuration they happen to know makes sense.

I don't understand - how can we do that without server cooperation?

[michaelpj]

I think you've already told me how to do what I want to do :)

The problem is: the server supports some configuration haskell.foo.bar, but I haven't written a defcustom-lsp for that, so the user wants to set it themselves, which is what the code you gave does, I think. So the server does support it, we just don't have a nice facade for it yet.

In the limit, you could imagine something like VSCode's settings.json where the user can really write a big structured object and get it forwarded to the server.

[yyoncho]

In the limit, you could imagine something like VSCode's settings.json where the user can really write a big structured object and get it forwarded to the server.

I havent tested it, but generally, you may register a shorter path and pass a map object and it will be sent to the server(that way you can pass all paths in one object). As a side note, I am planning to support settings.json.

[michaelpj]

I havent tested it, but generally, you may register a shorter path and pass a map object and it will be sent to the server

What happens if you have conflicting settings? e.g. if I set an object for foo and then a value for foo.bar?

[yyoncho]

I havent tested it, but generally, you may register a shorter path and pass a map object and it will be sent to the server

What happens if you have conflicting settings? e.g. if I set an object for foo and then a value for foo.bar?

That is what I haven't tested :)

[apodolsk]

Chiming in to second the request. I'm switching to lsp-mode because it solves a lot of my small eglot gripes, but I'm really feeling the absence of eglot's first-class ad-hoc LSP configuration support (https://www.gnu.org/software/emacs/manual/html_node/eglot/Project_002dspecific-configuration.html).

I think the rust-analyzer integration is a good example of the set of "blessed" vars lagging behind the implementation. There are some IMO must-have options ("don't make rust-analyzer contend on a directory lock with actual compilation"; "don't spit out a bunch of dead code warnings for your WIP project") which don't currently have pre-packaged support.

Interestingly, it seems that there's currently a mix of missing features that makes it impossible to set config generically for rust-analyzer in particular. I described my amateur investigation at #4506, but tl;dr is that I think rust-analyzer requires currently-unimplemented workspace/configuration support for lsp--set-configuration to work, and lsp-rust.el seems to just ignore the lsp-register-custom-settings setup in favor of its own settings code when setting up rust-analyzer initial params.

Point of that is to say that if ad-hoc config isn't a first class documented feature, I guess it's not just hard for people to figure out how to do it, it's also hard for lsp-mode to actually keep the feature working in the first place.