[FEATURE][DONE] support InitializeParams

[enderger]

Currently, it is impossible to configure servers like rust-analyzer due to the inability to set options via the InitializeParams message. Supporting this would allow the simple use of such servers.

[nemethf]

True, but according to the rust-analyzer docs "If a language client does not know about rust-analyzer's configuration options it can get sensible defaults by doing any of the following: Not sending initializationOptions..." . Which is what Eglot does at the moment.

[enderger]

Unfortunately, that limits the possibility of, for instance, expanding proc macros and preventing the whole project from rebuilding.

[nemethf]

then you can try to set the variable eglot-workspace-configuration in the project's .dir-locals.el file as described in the README and use the following snippet (updated):

(cl-defmethod eglot-initialization-options ((server eglot-lsp-server))
  (if (eq 'rust-mode (eglot--major-mode server))
      eglot-workspace-configuration
    eglot--{}))

(The proper way would be to create a defclass for rust-analyzer similarly to eglot-eclipse-jdt)
(Also, I've implemented some rust-analyzer specific extensions in my eglot-x.el, which might or might not be useful for you.)

[joaotavora]

Thanks @nemethf , for handling this. In your opinion, why can't rust-analyzer simply respond to M-x eglot-signal-didChangeConfiguration (after a change to eglot-workspace-configuration)?

[nemethf]

Rust-analyzer needs to do some stuffs right after it starts. It uses InitializeParams to customize these stuffs. The InitializeParams field is "standardized", but clients cannot provide a generic, server-independent implementation because InitializeParams can be Any. That is rust-analyzer expects this to be workspace-configuration, but a hypothetical server might expect this to be pi or empty.

IMHO the sensible thing to do for rust-analyzer would be to expect InitializeParams to be its (early) configuration, but when it's empty, it should wait a bit for the client to signal didChangeConfiguration. That way clients can have a generic implementation. However, it's easy to say what others should do.

[joaotavora]

However, it's easy to say what others should do.

Yes it is, but that doesn't mean it's wrong or useless. Have you or anyone said it to them?

Anyway, I'm starting to see, from your description, hat InitializeParams is really little more than typescriptish command line arguments, also arbitrary. So I wonder if there's space for this in eglot-server-programs . Not something the user could pass arbitrarily and interactively of course. Else, your class and defmethod idea is also don't, perhaps even conceptually cleaner, if a tad bit more verbose.

[nemethf]

However, it's easy to say what others should do.

Yes it is, but that doesn't mean it's wrong or useless. Have you or anyone said it to them?

I don't think anyone did. Looking at the stream of bugs they receive, it seems pointless without a patch.

Anyway, I'm starting to see, from your description, hat InitializeParams is really little more than typescriptish command line arguments, also arbitrary. So I wonder if there's space for this in eglot-server-programs . Not something the user could pass arbitrarily and interactively of course. Else, your class and defmethod idea is also don't, perhaps even conceptually cleaner, if a tad bit more verbose.

Do you have something like eglot-alternatives in mind? So that eglot-server-programs doesn't need to be changed. That would be great, but I don't see how it's possible to implement that easily.

[nemethf]

I've looked into this. Rust-analyzer uses InitializeParams to find the rustfmt executable and therefore to determine whether it is a documentFormattingProvider or not. Querying the client with workspace/configuration is indeed too late for that.

[TLATER]

Sorry to dig up old discussions, but I'm trying out trunk - this is especially painful with an unconfigured rust-analyzer, since trunk's trunk serve rebuilds on every file change as well as rust-analyzer, but the two build different targets by default.

This means that, every time I change anything, first rust-analyzer will rebuild the whole project (because trunk built a different target last time it served something), eglot will show rust-analyzer's lints, and then trunk will rebuild the whole project, dooming the whole thing to be repeated next time I save. Combined with rust's long build times, this means a good 5-10 minutes of CPU churning every time I make the tiniest change to my project.

Digging a bit through rust-analyzer issues, the vscode people seem to solve this like so:

((rust-mode
  . ((eglot-workspace-configuration
      . ((:rust-analyzer (:cargo (:target "wasm32-unknown-unknown"))))))))

But that won't work, and I was left scratching my head until I found this. Ultimately this isn't at all eglot's fault, but as-is this is horribly unusable.

Could we carve out a place to document how to handle quirky servers, and which servers are quirky in the first place? I really wasn't expecting this to be so broken.

[joaotavora]

But that won't work, and I was left scratching my head until I found this.

And I'm scratching my head 😅 what is "this"?What solution did you come up with, if any.

I also don't understand the original problem, but I don't think I have to, right? I just want to know what I'm your problem is related to InitializeParams.

[TLATER]

:) @nemethf 's snippet is ultimately the solution, I think:

(cl-defmethod eglot-initialization-options ((server eglot-lsp-server))
  (if (eq 'rust-mode (eglot--major-mode server))
      eglot-workspace-configuration
    eglot--{}))

i.e., I need to set rust-analyzer.cargo.target = "wasm32-unknown-unknown" at startup, but that doesn't work by default if I just add that to my .dir-locals.el because rust-analyzer requires configuration through initializeParams, which eglot doesn't add the user's .dir-locals.el to by default. So I need to force eglot to send that at the correct time by overriding that function?

[TLATER]

Aaaaaaah, ignore me, I've been chasing a complete red herring. For anyone else perhaps stumbling across this in the future, apparently rust is very sensitive to environment variables changing, and because I run emacs in daemon mode it has a different environment than my normal terminal.

Just running trunk serve as an async shell command in emacs completely solves the problem. Sorry for the noise @joaotavora, this has been an evening and a half :|

[joaotavora]

Ahh, ok. But at least I understand your solution for the red herring now.

I do wonder how to make fixes like this simple for users and not too onerous on Eglot's code base. I guess the approach you used is decent. And btw there's a section in the README "Handling quirky servers", i think.

[TLATER]

Yep, I saw that section. From my perspective a link in that section to a community-maintained list of server quirks, with some potential workarounds would be more than nice enough. As-is the section isn't that helpful, unless I specifically want to use cquery - I don't know whether my server is quirky in eglot's eyes until I'm waist-deep into chasing some odd misfeature and unsure which project is at fault.

Having a place where these things are documented would probably also help you figure out painpoints, making it easier to come up with a nice architecture to avoid such. Maybe I'm reinventing github issues, but I think there is some value to having an index into actual solutions people use in practice.

Eglot has been quite nice to use with respects to small hacks like this otherwise, owing largely to sane project size/architecture and integration into emacs, unlike certain other projects. So, thanks a lot for making eglot :)

[joaotavora]

Having a place where these things are documented would probably also help you figure out painpoints, making it easier to come up with a nice architecture to avoid such. Maybe I'm reinventing github issues, but I think there is some value to having an index into actual solutions people use in practice.

I guess you're sort of reinventing issues/discussions. But you're also right, I understand this. Maybe the wiki, but can everyone edit it? And if we let everyone edit it, is that a good idea?

For now, I think that if you have something to add about a given quirky server, or even a generic bug-chasing technique, or a technique to even know if a server is quirky, then making a well-worded PR to that section in the README.md is the way to go.

[TLATER]

That seems reasonable. I'd personally be worried about the readme growing a bit large this way, but perhaps I'm overestimating the number of quirks one could possibly document.

I'll use rust-analyzer a bit more and then see if I can condense something well-worded about what I learn. It might just be a note about being careful around didChangeConfiguration support, since vscode clearly handles that differently.

[joaotavora]

Thanks. If it runs too large we can make a SERVER-QUIRKS.md file.

[nemethf]

Commit 83a61f6 implemented the requested feature, so I mark this as done.

[joaotavora]

YOu should post a backtrace for that error. And provide the version of Eglot and Emacs you're working with.

[maxbrieiev]

Emacs is built from the recent master branch (commit 1b7a9753e105c5cc39b554c99bf93c7e2e9d6630)

Eglot:

     Version: 20220406.1459
     Commit: 2c34dae387c583aa307615779ff570a84d5e723c

It just prints this error in the *Messages* buffer without bringing up the debugger.
How can I enable it so the debugger pop ups?

[joaotavora]

M-x toggle-debug-on-error

[maxbrieiev]

Debugger entered--Lisp error: (wrong-type-argument stringp :initializationOptions)
  string-match("[\\\"]\\| " :initializationOptions)
  #f(compiled-function (str) #<bytecode 0x91de0cfac1d4728>)(:initializationOptions)
  mapconcat(#f(compiled-function (str) #<bytecode 0x91de0cfac1d4728>) ("myserver" "--stdio" :initializationOptions (foo bar)) " ")
  combine-and-quote-strings(("myserver" "--stdio" :initializationOptions (foo bar)))
  eglot--guess-contact(t)
  byte-code("\300\301\302!\303\"\207" [append eglot--guess-contact t (t)] 3)
  call-interactively(eglot record nil)
  command-execute(eglot record)
  execute-extended-command(nil "eglot" "eglot")
  funcall-interactively(execute-extended-command nil "eglot" "eglot")
  call-interactively(execute-extended-command nil nil)
  command-execute(execute-extended-command)

[joaotavora]

OK, I see the bug, pretty big one. Guess I didn't give this much testing 😓