eglot's interface for major modes

eglot's interface for major modes

[Sebastian Poeplau]

I'm using eglot with the Ada Language Server [1]. The server exposes a
custom command "als-other-file", whose purpose is to jump between
specification and implementation, a bit like `ff-find-other-file' for C.
Upon receiving the command, the server sends a "window/showDocument"
request [2] to the client, specifying the file to open.

Here's the code I use:

(defun ada-light-other-file ()
  "Jump from spec to body or vice versa using the Ada Language Server."
  (interactive)
  (if-let ((server (eglot-current-server)))
      (eglot-execute-command server
                             "als-other-file"
                             (vector (eglot--TextDocumentIdentifier)))
    (message "%s" "Not connected to the Ada Language Server")))

(unless (cl-find-method 'eglot-handle-request nil '(t (eql window/showDocument)))
  (cl-defmethod eglot-handle-request
    (_server (_method (eql window/showDocument)) &key uri &allow-other-keys)
    (find-file (eglot--uri-to-path uri))
    (list :success t)))

It works, but I wanted to discuss two things:

1. My function `ada-light-other-file' uses eglot's API
   `eglot-execute-command', but I wasn't able to find a public function
   that returns the document ID, hence my use of
   `eglot--TextDocumentIdentifier'. Do you think it makes sense to add
   one?

2. Should the handler for "window/showDocument" be part of eglot?

By the way, I edit Ada code with a custom major mode [3], but the actual
major mode being used shouldn't matter here.


[1] https://github.com/AdaCore/ada_language_server
[2] https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#window_showDocument
[3] https://github.com/sebastianpoeplau/ada-light-mode

Re: eglot's interface for major modes

[Stephen Leake]

Sebastian Poeplau <sebastian.poeplau@mailbox.org> writes:

> 2. Should the handler for "window/showDocument" be part of eglot?

Yes.

> By the way, I edit Ada code with a custom major mode [3],

The current ELPA ada-mode supports eglot as a backend; used that way, it
requires no compilation of Ada files. Have you tried that? If you have
questions about that, it would be best to use the ada-mode mailing list
(https://savannah.nongnu.org/mail/?group=ada-mode), or just email me
directly.

-- 
-- Stephe

Re: eglot's interface for major modes

[Felician Nemeth]

Stephen Leake <stephen_leake@stephe-leake.org> writes:
> Sebastian Poeplau <sebastian.poeplau@mailbox.org> writes:

> (defun ada-light-other-file ()

Would it make sense to locally set ff-other-file-alist to this?  That
way, users can globally bind ff-find-other-file and make it work with
both c-mode and ada-light-mode.

>> 2. Should the handler for "window/showDocument" be part of eglot?

See bug#62116

Re: eglot's interface for major modes

[Sebastian Poeplau]

>> (defun ada-light-other-file ()
>
> Would it make sense to locally set ff-other-file-alist to this?  That
> way, users can globally bind ff-find-other-file and make it work with
> both c-mode and ada-light-mode.

I may be mistaken, but my understanding of ff-other-file-alist is that
it needs to be set to a mapping between file extensions of specification
and implementation files; whatever the value, ff-find-other-file will
use the algorithm in find-file.el. My function, on the other hand,
relies on the language server to locate the "other file". But maybe one
could recommend that users remap their binding for ff-find-other-file to
ada-light-other-file in ada-light-mode.

>>> 2. Should the handler for "window/showDocument" be part of eglot?
>
> See bug#62116

Thanks for the pointer! Great to see that it's already being worked on.

Re: eglot's interface for major modes

[Felician Nemeth]

>>> (defun ada-light-other-file ()
>>
>> Would it make sense to locally set ff-other-file-alist to this?  That
>> way, users can globally bind ff-find-other-file and make it work with
>> both c-mode and ada-light-mode.
>
> I may be mistaken, but my understanding of ff-other-file-alist is that
> it needs to be set to a mapping between file extensions of specification
> and implementation files; whatever the value, ff-find-other-file will
> use the algorithm in find-file.el.

Even the algorithm can be redefined.  The latest version of the
documentation of variable ff-other-file-alist explains the details.

Eglot-x contains a possibly overly complicated example that also
delegates the ff-other-file functionality to LSP servers.
<https://github.com/nemethf/eglot-x>

But it's basically

  (setq-local ff-other-file-alist '(("*.ext ext-mode--ff-other-file)))

Re: eglot's interface for major modes

[Sebastian Poeplau]

>> I may be mistaken, but my understanding of ff-other-file-alist is that
>> it needs to be set to a mapping between file extensions of specification
>> and implementation files; whatever the value, ff-find-other-file will
>> use the algorithm in find-file.el.
>
> Even the algorithm can be redefined.  The latest version of the
> documentation of variable ff-other-file-alist explains the details.

Interesting! I checked the doc string in Emacs 28 before writing my
earlier message; it seems that a lot has changed since then :)

> Eglot-x contains a possibly overly complicated example that also
> delegates the ff-other-file functionality to LSP servers.
> <https://github.com/nemethf/eglot-x>
>
> But it's basically
>
>   (setq-local ff-other-file-alist '(("*.ext ext-mode--ff-other-file)))

That would indeed be a good fit! I'll have a look.

Re: eglot's interface for major modes

[João Távora]

On Sat, Apr 8, 2023 at 10:13 AM Felician Nemeth
<felician.nemeth@gmail.com> wrote:
>
> Stephen Leake <stephen_leake@stephe-leake.org> writes:
> > Sebastian Poeplau <sebastian.poeplau@mailbox.org> writes:
>
> > (defun ada-light-other-file ()
>
> Would it make sense to locally set ff-other-file-alist to this?  That
> way, users can globally bind ff-find-other-file and make it work with
> both c-mode and ada-light-mode.
>
> >> 2. Should the handler for "window/showDocument" be part of eglot?
>
> See bug#62116

Speaking of that, that bug seems to have stalled without feedback from
the OP, who provided a patch.  But you also had a patch stashed
somewhere, which I think we should just revive.  It was a simple
patch, AFAICR.

The main reason I haven't been working on this is that I don't
have any server that invokes window/showDocument that I can
test.  Maybe you do?

João

Re: eglot's interface for major modes

[Felician Nemeth]

João Távora <joaotavora@gmail.com> writes:

>> >> 2. Should the handler for "window/showDocument" be part of eglot?
>>
>> See bug#62116
>
> Speaking of that, that bug seems to have stalled without feedback from
> the OP, who provided a patch.  But you also had a patch stashed
> somewhere, which I think we should just revive.  It was a simple
> patch, AFAICR.

I can sent my patch with a correct commit log in a couple days.  Until
then it is here: https://github.com/joaotavora/eglot/pull/855

> The main reason I haven't been working on this is that I don't
> have any server that invokes window/showDocument that I can
> test.  Maybe you do?

Alan Donovan wrote his version for gopls, but he indicated my version is
not enough for gopls.

I tested my version with my own toy server.  Since I wrote both the
server and the client side, it is not good for general testing.

Sebastian's version does not fully implement the protocol, but the Ada
Langauge Server might be a good choice to test the implementation
against.  In his example, the server sends the window/showDocument
request in reaction to an eglot-execute-command client-request.  I don't
know if that complicates a potential testing process.  Probably not.

Felicián

Re: eglot's interface for major modes

[Sebastian Poeplau]

> Sebastian's version does not fully implement the protocol, but the Ada
> Langauge Server might be a good choice to test the implementation
> against.  In his example, the server sends the window/showDocument
> request in reaction to an eglot-execute-command client-request.  I don't
> know if that complicates a potential testing process.  Probably not.

If you'd like to experiment with the Ada Language Server, here's how to
set up a minimal project:

  minimal_project/
  ├── main.adb
  ├── main.ads
  └── project.gpr

The project definition in project.gpr is this:

  Project P is
     for Main use ("main.adb");
  end P;

The specification of the main unit (main.ads):

  procedure Main;

And the equally useful body (main.adb):

  procedure Main is null;

It's not a very useful project, but it's enough to make the server
respond to "als-other-file" in main.ad[bs].

You can download a prebuilt binary of the language server [1] or use the
Alire package manager to build your own [2]. Then you can use the custom
major mode from my initial message [3] and run the
`ada-light-other-file' command; the mode already monkey-patches eglot
with my (admittedly incomplete) handler for "window/showDocument".

If you want to silence the language server's warning about the lack of
an explicitly specified project file, set
`eglot-workspace-configuration' to (:ada (:projectFile "project.gpr")).


[1] https://github.com/AdaCore/ada_language_server/releases/tag/23.0.16
[2] https://alire.ada.dev/crates/ada_language_server.html
[3] https://github.com/sebastianpoeplau/ada-light-mode

Re: eglot's interface for major modes

[Sebastian Poeplau]

> The current ELPA ada-mode supports eglot as a backend; used that way, it
> requires no compilation of Ada files. Have you tried that? If you have
> questions about that, it would be best to use the ada-mode mailing list
> (https://savannah.nongnu.org/mail/?group=ada-mode), or just email me
> directly.

Your discussion of the Ada Language Server in the ada-mode manual is
actually what got me wondering how hard it would be to write a very
basic major mode for Ada that can work with a language server.

And then there's one more thing I'm exploring with this major mode. The
Language Server Protocol has a concept of "semantic tokens" [1] -
essentially server-provided fontification. The VS Code plugin for Ada
uses it, and I've been able to make it work in Emacs with lsp-mode.
(eglot support for semantic tokens seems to be work in progress [2].)
The approach is probably inferior to the tree-sitter support for Ada
that you and others are working on, but until the tree-sitter grammar
for Ada is ready and tree-sitter widely available it seemed like an
interesting option to play with.

[1] https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_semanticTokens
[2] https://github.com/joaotavora/eglot/pull/839

Re: eglot's interface for major modes

[Stephen Leake]

Sebastian Poeplau <sebastian.poeplau@mailbox.org> writes:

> And then there's one more thing I'm exploring with this major mode. The
> Language Server Protocol has a concept of "semantic tokens" [1] -
> essentially server-provided fontification. The VS Code plugin for Ada
> uses it, and I've been able to make it work in Emacs with lsp-mode.
> (eglot support for semantic tokens seems to be work in progress [2].)

That will be supported by ada-mode when eglot supports it. I was also
working on a patch for eglot for that
(https://github.com/stephe-ada-guru/eglot), but decided to work on
tree-sitter first, partly because of bugs in ada_language_server, mostly
because ada_language_server is not very good for indenting, because the error
recovery is poor.

> The approach is probably inferior to the tree-sitter support for Ada
> that you and others are working on, 

Why do you think that? ada_language_server does some semantic analysis
(mostly name resolution), so the results are more precise than a syntax
parser like wisitoken or tree-sitter can provide. ada_language_server is
not incremental, but it's _very_ fast, so you have to have _very_ large
files to notice a delay while editing.

-- 
-- Stephe

Re: eglot's interface for major modes

[Sebastian Poeplau]

>> The approach is probably inferior to the tree-sitter support for Ada
>> that you and others are working on,
>
> Why do you think that? ada_language_server does some semantic analysis
> (mostly name resolution), so the results are more precise than a syntax
> parser like wisitoken or tree-sitter can provide. ada_language_server is
> not incremental, but it's _very_ fast, so you have to have _very_ large
> files to notice a delay while editing.

My point was more about the out-of-process nature of language servers.
Having to send JSON messages back and forth on every buffer change to
support fontification seems less efficient than having a good in-process
parser, even if the message format compresses the data like LSP does
with semantic tokens.

Re: eglot's interface for major modes

[Stephen Leake]

Sebastian Poeplau <sebastian.poeplau@mailbox.org> writes:

>>> The approach is probably inferior to the tree-sitter support for Ada
>>> that you and others are working on,
>>
>> Why do you think that? ada_language_server does some semantic analysis
>> (mostly name resolution), so the results are more precise than a syntax
>> parser like wisitoken or tree-sitter can provide. ada_language_server is
>> not incremental, but it's _very_ fast, so you have to have _very_ large
>> files to notice a delay while editing.
>
> My point was more about the out-of-process nature of language servers.
> Having to send JSON messages back and forth on every buffer change to
> support fontification seems less efficient than having a good in-process
> parser, even if the message format compresses the data like LSP does
> with semantic tokens.

Yes, LSP moves more electrons than the tree-sitter module interface. I
doubt the difference is measurable in battery life or watt-hours.

What matters most is that the response time be imperceptible in typical
use. In my limited use of ada-language-server via eglot, it is fast
enough (when it's not broken, which is often :().

-- 
-- Stephe

Re: eglot's interface for major modes

[Sebastian Poeplau]

> What matters most is that the response time be imperceptible in typical
> use. In my limited use of ada-language-server via eglot, it is fast
> enough (when it's not broken, which is often :().

In which situations does it break for you? It has been quite stable on
the projects that I've used it with.

Re: eglot's interface for major modes

[Stephen Leake]

Sebastian Poeplau <sebastian.poeplau@mailbox.org> writes:

>> What matters most is that the response time be imperceptible in typical
>> use. In my limited use of ada-language-server via eglot, it is fast
>> enough (when it's not broken, which is often :().
>
> In which situations does it break for you? It has been quite stable on
> the projects that I've used it with.

https://github.com/AdaCore/ada_language_server/issues?q=is%3Aissue+is%3Aclosed+author%3Astephe-ada-guru

It seems all those issues are fixed in the devel version; I have not
checked if there is a recent release.

-- 
-- Stephe