bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Felician Nemeth
Subject: bug#62198: [PATCH] Eglot: Send clientInfo during the initialize request
Date: Wed, 22 Mar 2023 17:05:08 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

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

Attachment: 0001-Eglot-Send-clientInfo-during-the-initialize-request.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]