Subject: bug#62198: [PATCH] Eglot: Send clientInfo during the initialize request

From: Felician Nemeth <[email-masked]>
Date: Wed, 22 Mar 2023 17:05:08 +0100

>> So maybe clientInfo should just send the name of the client if
>> João is not happy with the previous approach finding out the version of
>> Eglot.
>
> I don't know if I'm happy with it, since I'm not familiar with what
> it does.

This is eglot--version in my original patch:

  (defconst eglot--version
    (eval-when-compile
      (when byte-compile-current-file
        (require 'lisp-mnt)
        (lm-version byte-compile-current-file)))
    "The version as a string of this version of Eglot.
  It is nil if Eglot is not byte-complied.")

It does something similar to sly-version, but instead of manually
parsing the source file it relies on `lm-version' of the lisp-mnt
package.  (package.el also uses lisp-mnt to parse "header comments".)
However, lm-version needs a file argument to parse.  If eglot.el is
byte-compiled, then byte-compile-current-file will be set to eglot.el
during compile-time and eglot--version won't have a run-time calculation
cost.

> The version could be useful.  The problem is that it is tricky
> to get right, meaning something that you can really rely on.  Ideally
> I'd like to know two things in the log transcript some hypothetical
> bug reporter shares:
>
> 1. Is this an unmodified GNU(-devel) ELPA version of Eglot installed by
>    the only officially supported `M-x package-install` method?  If so,
>    what version exactly?
>
> 2. This is something else, a user compilation, a straight-installed
>    package, nix installation (never tried these, but they show
>    up in the wild a lot, and are problematic like in
>    https://github.com/joaotavora/eglot/discussions/1182).
>
> I don't think any more granularity within 2 would be very useful,
> especially to the server devs.  

I don't know how to answer these questions.

> Although it _could_ be useful to somehow debug -- not via LSP messages
> to server, but in the events log as an internal message -- the
> versions of the packages that Eglot depends on.  But that's a broader
> idea, I think, and one more suitable for a future M-x
> report-bug-in-elpa-package.

I think it is possible write the versions of Eglot and its dependencies
into eglot-events-buffer with the help of list-mnt, but I don't think
Eglot should send this in clientInfo.

> If this is not easy to do without complex libraries, i'd prefer just to
> send the client name via LSP.

I've attached a simple patch that sends just the client name if you
decide to go this way.

Thanks.
>From d88fbc30335fa4f68e1dfa339fb9e23f80eadbef Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Felici=C3=A1n=20N=C3=A9meth?= <[email-masked]>
Date: Wed, 15 Mar 2023 12:34:06 +0100
Subject: [PATCH] Eglot: Send clientInfo during the initialize request

clientInfo arrived in LSP 3.15.0.  LSP clients can use clientInfo to
identify themselves in the initialize request.  This is generally
useful for various debugging tasks.

* lisp/progmodes/eglot.el (eglot--connect): Send clientInfo.
---
 lisp/progmodes/eglot.el | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el
index 037cc87148..91fa00d4b7 100644
--- a/lisp/progmodes/eglot.el
+++ b/lisp/progmodes/eglot.el
@@ -1310,6 +1310,7 @@ eglot--connect
                                         (eq (jsonrpc-process-type server)
                                             'network))
                               (emacs-pid))
+                            :clientInfo '(:name "Eglot")
                             ;; Maybe turn trampy `/ssh:foo@bar:/path/to/baz.py'
                             ;; into `/path/to/baz.py', so LSP groks it.
                             :rootPath (file-local-name
-- 
2.30.2