Open nemethf opened 4 years ago
It would generally be useful for the various accessors of eglot-lsp-server
to be marked public.
There are use-cases (like private LSP backend implementations where contributing server-specific classes to eglot is not an option) for defining LSP classes outside of eglot.el
, and that leads to using internal accessors to modify things like the spinner state of a server.
Vincent Ambo notifications@github.com writes:
It would generally be useful for the various accessors of eglot-lsp-server to be marked public.
There are use-cases (like private LSP backend implementations where contributing server-specific classes to eglot is not an option) for defining LSP classes outside of eglot.el,
Private or not, definiting LSP classes outside eglot is very much supported.
and that leads to using internal accessors to modify things like the spinner state of a server.
This has to be on a case by case basis. If we make all the various accessors public, as you seem to suggest, we lock ourselves in a particular implementation, which is a bad thing.
So you need to provide a little bit more specific about what exactly you are trying to achieve. Is it something like this?
(cl-defmethod eglot-handle-notification
((server eglot-rls) (_method (eql window/progress))
&key id done title message &allow-other-keys)
"Handle notification window/progress"
(setf (eglot--spinner server) (list id title done message)))
If so then, maybe we should come up with a better abstraction than "spinner". Or is it something else?
João
https://github.com/joaotavora/eglot/issues/353#issuecomment-557171183