search

joaotavora / eglot

A client for Language Server Protocol servers
GNU General Public License v3.0
2.27k stars 200 forks source link

Implement per-server variable bindings #152

Open mkcms opened 6 years ago

mkcms commented 6 years ago

Per https://github.com/joaotavora/eglot/pull/125#issuecomment-438825967 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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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...