[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.
0001-Eglot-Send-clientInfo-during-the-initialize-request.patch
Description: Text Data
- bug#62198: [PATCH] Eglot: Send clientInfo during the initialize request, Felician Nemeth, 2023/03/15
- bug#62198: [PATCH] Eglot: Send clientInfo during the initialize request, João Távora, 2023/03/15
- bug#62198: [PATCH] Eglot: Send clientInfo during the initialize request, Felician Nemeth, 2023/03/16
- bug#62198: [PATCH] Eglot: Send clientInfo during the initialize request, Michael Albinus, 2023/03/17
- bug#62198: [PATCH] Eglot: Send clientInfo during the initialize request, Felician Nemeth, 2023/03/19
- bug#62198: [PATCH] Eglot: Send clientInfo during the initialize request, João Távora, 2023/03/19
- bug#62198: [PATCH] Eglot: Send clientInfo during the initialize request,
Felician Nemeth <=
- bug#62198: [PATCH] Eglot: Send clientInfo during the initialize request, João Távora, 2023/03/22
- bug#62198: [PATCH] Eglot: Send clientInfo during the initialize request, Felician Nemeth, 2023/03/23