Implement per-server variable bindings

[mkcms]

Per #125 (comment)
The idea is to have a way to automatically bind some buffer-local variables for chosen servers.
For example, eglot-move-to-column-function needs to be set for specific servers buffer-locally.

[joaotavora]

This should probably be a generic function on the server right?

(cl-defgeneric eglot-server-bindings (server) ...)

sounds right, but what to do when eglot disconnects? Restore the bindings as they were before connection?

[mkcms]

This should probably be a generic function on the server right?

Hmm, what's wrong with having an alist, like you suggested? I think it would be more user friendly.

what to do when eglot disconnects? Restore the bindings as they were before connection?

I thought we could just set them in eglot--managed-mode and when eglot shuts down, we don't restore anything. I think that for most use cases, users enable eglot in a buffer, and it is connected until the user kills that buffer.

[joaotavora]

Hmm, what's wrong with having an alist, like you suggested? I think it would be more user friendly.

The generic function would return an alist.

I thought we could just set them in eglot--managed-mode and when eglot shuts down, we don't restore anything. I think that for most use cases, users enable eglot in a buffer, and it is connected until the user kills that buffer.

Good idea, this seems a reasonable cop-out away from the problem :-)

[joaotavora]

The generic function would return an alist.

Perhaps I didn't explain myself very well. ((VAR .VALUE)) is the bindings alist I am thinking of. If you meant an alist ((SERVER . BINDINGS)), then I think that the best way to establish an association between a server and something else, currently, is by using cl-defmethod on the server class.

[mkcms]

The generic function would return an alist.

A generic function makes sense, I'm just in favor of a variable because, at least for me, they're easier to use. With a generic function I actually have to edit my init file, with a variable I can just edit dir-locals.
You also mentioned here that we could match the server executable.

[joaotavora]

A generic function makes sense, I'm just in favor of a variable because, at least for me, they're easier to use. With a generic function I actually have to edit my init file, with a variable I can just edit dir-locals.

But are these variables intended to be set by the user regularly per-project? Or are they properties/quirks of the servers themselves that we sometimes handle in eglot.el?

[mkcms]

But are these variables intended to be set by the user regularly per-project? Or are they properties/quirks of the servers themselves that we sometimes handle in eglot.el?

Oh, I thought they were meant to be set by users (your suggested variable name implies it, I think). If it's supposed to be set internally by us, then defgeneric would probably be the way to go... Although maintaining different server variables in eglot will take some work.

[joaotavora]

Oh, I thought they were meant to be set by users (your suggested variable name implies it, I think).

Yes, if I thought that earlier, then I was wrong, I think.

Although maintaining different server variables in eglot will take some work.

Sure, but all of this is a way for us to escape non-conforming servers, which is something we live with. Eventually, as servers become more and more conforming (yeah right), these things would fade...