Re: [GNU ELPA] eglot-x.el: Protocol extensions for Eglot

[Felician Nemeth]

Eli Zaretskii <eliz@gnu.org> writes:

> IMO, it is no longer reasonable to have extensions that cannot be
> possibly supported by the version of Eglot that comes with Emacs.
> IOW, if someone wants to download and install your extensions, we
> should try not to force them to also download and install a newer
> version of Eglot from ELPA.  I hope this is possible.

Yes, I think so.  I'll keep this in mind when I modify eglot-x.

> What mechanisms aside of advice can be used to extend Eglot so that it
> could optionally support those extensions?

1. Eglot support editing remote files when the source files and the LSP
   server are on the same remote system.  There is an extension that
   makes possible to edit files when the files and the server are on
   different systems.

   Eglot's own remote file support rewrites filenames, which interfered
   with my implementation.  My solution was basically to selective
   advice some Eglot functions to make file-remote-p always return nil.

   An alternative approach could be an Eglot configuration variable to
   optionally disable its tramp support.


2. There's a clangd extension for encoding negotiation.  The server
   sends the result of the negotiation in an InitializeResult response.
   Eglot saves the capabilities part of this response, which is usually
   enough, but this extension puts the negotiated encoding elsewhere.

   Eglot-x uses a series of add-advices calls to copy the encoding
   string into the exposed capabilities variable.

   An alternative approach for Eglot could be to save the whole
   InitializeResult response as well.

   However, the encoding negotiation extension has been standardized (in
   a slightly different way).  Eglot does support the standardized
   feature.  So maybe it is enough to wait a bit until clangd implements
   the new standard and then this feature can be removed from eglot-x.


3. Eglot uses the eglot--apply-text-edits defun to apply server
   initiated edits.  There is an extension that allows the server to
   send the edits in a different format (snippet-text-edits).

   Eglot-x puts an advise on eglot--apply-text-edits to check the format
   of the edits and act accordingly.

   I don't know how to avoid this advice.


4. Eglot-x puts an advice on eglot--mode-line-format in order to display
   the server's status (which the server sends if the client supports an
   LSP extension.)

   I think eglot-x should just use its own space in the mode line.  I
   think I just wasn't able to figure out how it could be put next to
   Eglot's mode-line.


5. Finally, eglot-x stores its own state in an instance of the
   eglot-lsp-server.  eglot-lsp-server is defined with defclass, so it
   is possible to add new slots to it without any problem.

   For some reason I just wanted to hide these eglot-x specific slots
   from Eglot.  It think the solution is to simply not use an advice
   here.