unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* eglot's interface for major modes
@ 2023-04-07 18:20 Sebastian Poeplau
  2023-04-07 21:26 ` Stephen Leake
  0 siblings, 1 reply; 15+ messages in thread
From: Sebastian Poeplau @ 2023-04-07 18:20 UTC (permalink / raw)
  To: emacs-devel

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



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: eglot's interface for major modes
  2023-04-07 18:20 eglot's interface for major modes Sebastian Poeplau
@ 2023-04-07 21:26 ` Stephen Leake
  2023-04-08  9:13   ` Felician Nemeth
  2023-04-08  9:26   ` Sebastian Poeplau
  0 siblings, 2 replies; 15+ messages in thread
From: Stephen Leake @ 2023-04-07 21:26 UTC (permalink / raw)
  To: Sebastian Poeplau; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: eglot's interface for major modes
  2023-04-07 21:26 ` Stephen Leake
@ 2023-04-08  9:13   ` Felician Nemeth
  2023-04-08  9:37     ` Sebastian Poeplau
  2023-04-13 16:22     ` João Távora
  2023-04-08  9:26   ` Sebastian Poeplau
  1 sibling, 2 replies; 15+ messages in thread
From: Felician Nemeth @ 2023-04-08  9:13 UTC (permalink / raw)
  To: Stephen Leake; +Cc: Sebastian Poeplau, emacs-devel

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



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: eglot's interface for major modes
  2023-04-07 21:26 ` Stephen Leake
  2023-04-08  9:13   ` Felician Nemeth
@ 2023-04-08  9:26   ` Sebastian Poeplau
  2023-04-08 10:30     ` Stephen Leake
  1 sibling, 1 reply; 15+ messages in thread
From: Sebastian Poeplau @ 2023-04-08  9:26 UTC (permalink / raw)
  To: Stephen Leake; +Cc: emacs-devel

> 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



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: eglot's interface for major modes
  2023-04-08  9:13   ` Felician Nemeth
@ 2023-04-08  9:37     ` Sebastian Poeplau
  2023-04-11 14:05       ` Felician Nemeth
  2023-04-13 16:22     ` João Távora
  1 sibling, 1 reply; 15+ messages in thread
From: Sebastian Poeplau @ 2023-04-08  9:37 UTC (permalink / raw)
  To: Felician Nemeth; +Cc: Stephen Leake, emacs-devel

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



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: eglot's interface for major modes
  2023-04-08  9:26   ` Sebastian Poeplau
@ 2023-04-08 10:30     ` Stephen Leake
  2023-04-08 10:53       ` Sebastian Poeplau
  0 siblings, 1 reply; 15+ messages in thread
From: Stephen Leake @ 2023-04-08 10:30 UTC (permalink / raw)
  To: Sebastian Poeplau; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: eglot's interface for major modes
  2023-04-08 10:30     ` Stephen Leake
@ 2023-04-08 10:53       ` Sebastian Poeplau
  2023-04-12 23:06         ` Stephen Leake
  0 siblings, 1 reply; 15+ messages in thread
From: Sebastian Poeplau @ 2023-04-08 10:53 UTC (permalink / raw)
  To: Stephen Leake; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: eglot's interface for major modes
  2023-04-08  9:37     ` Sebastian Poeplau
@ 2023-04-11 14:05       ` Felician Nemeth
  2023-04-13 19:24         ` Sebastian Poeplau
  0 siblings, 1 reply; 15+ messages in thread
From: Felician Nemeth @ 2023-04-11 14:05 UTC (permalink / raw)
  To: Sebastian Poeplau; +Cc: Stephen Leake, emacs-devel

>>> (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)))



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: eglot's interface for major modes
  2023-04-08 10:53       ` Sebastian Poeplau
@ 2023-04-12 23:06         ` Stephen Leake
  2023-04-13 19:23           ` Sebastian Poeplau
  0 siblings, 1 reply; 15+ messages in thread
From: Stephen Leake @ 2023-04-12 23:06 UTC (permalink / raw)
  To: Sebastian Poeplau; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: eglot's interface for major modes
  2023-04-08  9:13   ` Felician Nemeth
  2023-04-08  9:37     ` Sebastian Poeplau
@ 2023-04-13 16:22     ` João Távora
  2023-04-13 17:43       ` Felician Nemeth
  1 sibling, 1 reply; 15+ messages in thread
From: João Távora @ 2023-04-13 16:22 UTC (permalink / raw)
  To: Felician Nemeth; +Cc: Stephen Leake, Sebastian Poeplau, emacs-devel

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



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: eglot's interface for major modes
  2023-04-13 16:22     ` João Távora
@ 2023-04-13 17:43       ` Felician Nemeth
  2023-04-13 19:36         ` Sebastian Poeplau
  0 siblings, 1 reply; 15+ messages in thread
From: Felician Nemeth @ 2023-04-13 17:43 UTC (permalink / raw)
  To: João Távora; +Cc: Stephen Leake, Sebastian Poeplau, emacs-devel

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



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: eglot's interface for major modes
  2023-04-12 23:06         ` Stephen Leake
@ 2023-04-13 19:23           ` Sebastian Poeplau
  2023-04-15 16:38             ` Stephen Leake
  0 siblings, 1 reply; 15+ messages in thread
From: Sebastian Poeplau @ 2023-04-13 19:23 UTC (permalink / raw)
  To: Stephen Leake; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: eglot's interface for major modes
  2023-04-11 14:05       ` Felician Nemeth
@ 2023-04-13 19:24         ` Sebastian Poeplau
  0 siblings, 0 replies; 15+ messages in thread
From: Sebastian Poeplau @ 2023-04-13 19:24 UTC (permalink / raw)
  To: Felician Nemeth; +Cc: Stephen Leake, emacs-devel

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



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: eglot's interface for major modes
  2023-04-13 17:43       ` Felician Nemeth
@ 2023-04-13 19:36         ` Sebastian Poeplau
  0 siblings, 0 replies; 15+ messages in thread
From: Sebastian Poeplau @ 2023-04-13 19:36 UTC (permalink / raw)
  To: Felician Nemeth; +Cc: João Távora, Stephen Leake, emacs-devel

> 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



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: eglot's interface for major modes
  2023-04-13 19:23           ` Sebastian Poeplau
@ 2023-04-15 16:38             ` Stephen Leake
  0 siblings, 0 replies; 15+ messages in thread
From: Stephen Leake @ 2023-04-15 16:38 UTC (permalink / raw)
  To: Sebastian Poeplau; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2023-04-15 16:38 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-04-07 18:20 eglot's interface for major modes Sebastian Poeplau
2023-04-07 21:26 ` Stephen Leake
2023-04-08  9:13   ` Felician Nemeth
2023-04-08  9:37     ` Sebastian Poeplau
2023-04-11 14:05       ` Felician Nemeth
2023-04-13 19:24         ` Sebastian Poeplau
2023-04-13 16:22     ` João Távora
2023-04-13 17:43       ` Felician Nemeth
2023-04-13 19:36         ` Sebastian Poeplau
2023-04-08  9:26   ` Sebastian Poeplau
2023-04-08 10:30     ` Stephen Leake
2023-04-08 10:53       ` Sebastian Poeplau
2023-04-12 23:06         ` Stephen Leake
2023-04-13 19:23           ` Sebastian Poeplau
2023-04-15 16:38             ` Stephen Leake

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).