How do I share a single server instance across multiple strongly related modes (e.g. c-mode, c++-mode)?

[ejelly]

It's not uncommon for projects to be a mixture of C and C++, which naturally leads to files of the project being opened in either c-mode or c++-mode. Sometimes e.g. Objective-C is also in the mix.

However I cannot find out how to specify a server such that the instance is shared between those modes. eglot seems to want to fire up a new instance for each mode. That means navigating between e.g. C and C++ files doesn't work. I'm relatively sure that clangd itself can do this, though (I might be wrong)...

How can I fix this?

[joaotavora]

If you have C and C++ files in the same project, the default spec in eglot-server-programs:

((c-mode c-ts-mode c++-mode c++-ts-mode objc-mode)
                                 . ,(eglot-alternatives
                                     '("clangd" "ccls")))

Does this perfectly.

eglot seems to want to fire up a new instance for each mode.

I don't see that and you haven't explained what you do to make that happen, but I've just tried a simple directory with a C and C++ file, which in my system are visited in c-ts-mode and c++-ts-mode and everything just works. Would be the same for c-mode and c++-mode.

[ejelly]

I need some interactive input from the user (me) to compute the correct clangd and pass the right --compile-commands-dir to it. It's a project that uses multiple SDKs, among other things. That does not mean that I'm using multiple SDKs (among other things) within a single eglot session, just that I need to choose the configuration that I want for the session upfront.

Originally I had a shell script and stuff like clangd wrapper binaries to set things up in the working directory, but obviously that's more painful, so at some point I sat down and wrote an elisp wrapper function for lsp-mode that computed candidates from some metadata in the project and let me choose how the session should be set up.

I've since modified the wrapper function to call eglot instead, and that also works for the most part, except that, as said, I wasn't able to specify multiple modes for the session.

[joaotavora]

I need some interactive input from the user (me) to compute the correct clangd and pass the right --compile-commands-dir to it. It's a project that uses multiple SDKs, among other things.

Ah! I'm not kidding: I have the exact same problem at $DAYJOB. I use C-u M-x eglot and then at most a couple of M-p 's to find the invocation with the right clangd and --compile-commands-dir where I keep a carefully handcrafted compile_commands.json file.

But you and I just have a directory local value for eglot-server-programs at the root dir of our project . I just never got around to it, cause my Eglot sessions are so long lived and the C-u M-x eglot works so well.

Both these solutions seem way easier than wrapper scripts and extra Elisp code. Also, keep in mind you can do directory-local variables without storing files on your file system (alamost nobody at my job uses Emacs, so putting a .dir-locals.el there would freak people out).

[ejelly]

I use C-u M-x eglot and then at most a couple of M-p 's to find the invocation with the right clangd and --compile-commands-dir where I keep a carefully handcrafted compile_commands.json file.

That would be a good idea, but in my case the possible configurations are not only a cartesian product of several different axes, the resulting paths are also highly dynamic, meaning even the same configuration can have (for example) a totally different clangd path the next day.

Believe me, I tried to slice and dice the problem several ways, at the end of the day simply asking for some input and computing the right paths is really the best way to go. It's what the shell tools that are part of the project do as well (though they usually take the simple user input as command line arguments, not interactively, as makes sense for shell tools).

Asking interactively also means I can benefit from completion, which in this case is really helpful.

The project specific configuration is neat and it probably mitigates the need for putting heuristics into my eglot-server-programs, but that's the secondary problem. The primary problem is that I need user input and then to compute the paths from that. And what I have so far with (interactive ...) works really well, giving me the proper autocompletion and everything. The only thing that's missing is multiple modes.

[ejelly]

Another thing: The compile_commands.json is also massive and changes all the time, even if you don't take into account the changes that are just the result from selecting another SDK. My elisp function parses it and gets some stuff from out of it.

[joaotavora]

Believe me, I tried to slice and dice the problem several ways,

Have you tried replacing the _value _keyed by (c++-mode c++-ts-mode c-mode c-ts-mode) entry in eglot-server-program with a function.

If you want, you can do this replacement only directory-locally.

Read the doc of eglot-server-programs.

* A function of a single argument producing any of the above
  values for CONTACT.  The argument's value is non-nil if the
  connection was requested interactively (e.g. from the `eglot'
  command), and nil if it wasn't (e.g. from `eglot-ensure').  If
  the call is interactive, the function can ask the user for
  hints on finding the required programs, etc.  Otherwise, it
  should not ask the user for any input, and return nil or signal
  an error if it can't produce a valid CONTACT.  The helper
  function `eglot-alternatives' (which see) can be used to
  produce a function that offers more than one server for a given
  MAJOR-MODE.

Note the phrase If the call is interactive, the function can ask the user for hints on finding the required programs, etc..

So all your completing-read and crazy compile_commands.json schnitzels would go into this function. They should kick in when the argument is t. If you don't know what to do in that function if the argument is nil ,no problem, just error out. It's only used for eglot-ensure.

If at any point your computation discovers that the current buffer belongs to a normal bog-standard project, you can just return a list of a single string "clangd" or delegate to eglot-alternatives.

Bottom line, so far, from your description, I see absolutely no need for a my-eglot command. After you set it up like this, the amount of brainpower you expend in deciding whether to call M-x my-eglot or M-x eglot should be the same you use when answering the yes-no question "Is this one of those super-duper projects?"

[ejelly]

Thank you. As long as I can figure out the proper way to call the function in eglot-server-programs as if it was directly called interactively, properly resolving its (interactive ...) spec with user input, it should be relatively easy to convert my wrapper into an eglot-server-programs function instead, and indeed cleaner.

I thought call-interactively or command-execute would be that way, but reading its documentation I'm not so sure. Anyway, I'm sure there must be a proper way, and at this point this of course has nothing to do with eglot anymore.

[joaotavora]

OK, and good luck, but:

the proper way to call the function in eglot-server-programs

Just to make sure you understand: one doesn't call this function (at least the one I'm proposing), one merely registers it and it gets called on one's behalf. Because of that, the function doesn't need an interactive spec. See eglot-alternatives for an example a function that returns such a function. The lambda it returns takes an interactive arg but doesn't have an interactive spec. You shouldn't need this higher-orderness in your case though (unless you want to take decisions at config-loading time, which you probably don't).

[ejelly]

I totally understand! But I would like to call a function that uses (interactive ...). Partly because I've already written the code that way, but more importantly because (interactive ...) has some very convenient features, and if possible I'd like to avoid recreating that using completing-read etc.

But if that doesn't work, I'll abandon any existing (interactive ...) code I have and implement it differently.

[joaotavora]

The only interesting features I see of interactive are shortcuts like D to read-directory-name when a simple string is given. I find this rather cryptic myself. Everything you can do with an interactive spec you can do with simple Elisp code. But if you want to keep it, you can put it in a separate function and then use call-interactively to get the arguments out of it.

(defun get-arguments-with-string-interactive-spec (&rest args) (interactive "Ddirectory? ") args)

(call-interactively 'get-arguments-with-string-interactive-spec)