GNU bug report logs - #62198
[PATCH] Eglot: Send clientInfo during the initialize request

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 62198 in the body.
You can then email your comments to 62198 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Felician Nemeth <felician.nemeth <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Eglot: Send clientInfo during the initialize request
Date: Wed, 15 Mar 2023 12:53:58 +0100

[Message part 1 (text/plain, inline)]

I originally posted this patch on github:
https://github.com/joaotavora/eglot/pull/818

João requested to resubmit it here.

To recap: 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.

[0001-Eglot-Send-clientInfo-during-the-initialize-request.patch (text/x-diff, attachment)]

Message #8 received at 62198 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: Felician Nemeth <felician.nemeth <at> gmail.com>
Cc: 62198 <at> debbugs.gnu.org
Subject: Re: bug#62198: [PATCH] Eglot: Send clientInfo during the initialize
 request
Date: Wed, 15 Mar 2023 20:38:10 +0000

Felician Nemeth <felician.nemeth <at> gmail.com> writes:

> I originally posted this patch on github:
> https://github.com/joaotavora/eglot/pull/818
>
> João requested to resubmit it here.
>
> To recap: 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.
>
> From 5fe9d054845382ce74c29bb338ffc737b0770542 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Felici=C3=A1n=20N=C3=A9meth?= <felician.nemeth <at> gmail.com>
> 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--version): New defconst.
> (eglot--connect): Send clientInfo using eglot--version.
> * test/lisp/progmodes/eglot-tests.el
> (eglot-test-client-info): New test.
> ---
>  lisp/progmodes/eglot.el            | 12 ++++++++++++
>  test/lisp/progmodes/eglot-tests.el | 18 ++++++++++++++++++
>  2 files changed, 30 insertions(+)
>
> diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el
> index 037cc87148..f89c47ac4f 100644
> --- a/lisp/progmodes/eglot.el
> +++ b/lisp/progmodes/eglot.el
> @@ -410,6 +410,14 @@ eglot-withhold-process-id
>  
>  ;;; Constants
>  ;;;
> +(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.")

I'm not familiar with this lisp-mnt.el library.  Is it the kosher way to
get version introspection for Elisp libs?  Why is it nil if Eglot is not
byte-compiled, couldn't we get it by looking at load-file-name?

Can we somehow get the Emacs.git SHA in there as well?

> @@ -1310,6 +1318,10 @@ eglot--connect
>                                          (eq (jsonrpc-process-type server)
>                                              'network))
>                                (emacs-pid))
> +                            :clientInfo (if eglot--version
> +                                            `(:name "Eglot"
> +                                              :version ,eglot--version)
> +                                          '(:name "Eglot"))

I'd rather just :name "Eglot" :version "unknown" if we don't have it.

> +  (eglot--with-fixture
> +   `(("project" . (("coiso.py" . "def coiso: pass"))))
> +   (with-current-buffer
> +       (eglot--find-file-noselect "project/coiso.py")
> +     (eglot--sniffing (:client-requests c-reqs)
> +       (should (eglot--tests-connect 10))
> +       (eglot--wait-for (c-reqs 10)
> +           (&key _id method params &allow-other-keys)
> +         (when (string= method "initialize")
> +           (let* ((clientInfo (plist-get params :clientInfo))
> +                  (name (plist-get clientInfo :name))
> +                  (version (plist-get clientInfo :version)))
> +             (should (equal name "Eglot"))
> +             (should (version<= "1.8" (or version "0"))))))))))

Thanks.  Do we really need a test for this?  I suppose it's good
practice, but seems a but too much.  We could put this check in some
other "basic" test, save a bit of time.

João

Message #11 received at 62198 <at> debbugs.gnu.org (full text, mbox):

From: Felician Nemeth <felician.nemeth <at> gmail.com>
To: João Távora <joaotavora <at> gmail.com>
Cc: 62198 <at> debbugs.gnu.org
Subject: Re: bug#62198: [PATCH] Eglot: Send clientInfo during the initialize
 request
Date: Thu, 16 Mar 2023 17:47:03 +0100

[Message part 1 (text/plain, inline)]

>> +(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.")
>
> I'm not familiar with this lisp-mnt.el library.  Is it the kosher way to
> get version introspection for Elisp libs?

I haven't found the prior art for this.  trampver.el repeats the header
info, so when the version changes it should be updated two places, which
(I think) is an antipattern.  For "normal" users, Eglot should come with
Emacs or be installed from ELPA.  In both cases, Eglot is byte-compiled.

> Why is it nil if Eglot is not byte-compiled, couldn't we get it by
> looking at load-file-name?

Yes, that's a possibily, but that won't be perfect either.  I tend to
eval-buffer when I work on Eglot.

> Can we somehow get the Emacs.git SHA in there as well?

There is `emacs-repository-get-version', but according to its docstring
it doesn't work all the time.  trampver.el is a good example how
complicated its usage.

Do you intend to rely on the clientInfo in bug reports?  I think it's
safer to ask for the exact details if the user is running a not released
version.

>> +                            :clientInfo (if eglot--version
>> +                                            `(:name "Eglot"
>> +                                              :version ,eglot--version)
>> +                                          '(:name "Eglot"))
>
> I'd rather just :name "Eglot" :version "unknown" if we don't have it.

"Version" is optional.  I think it shouldn't be specified if it is
unknown.  Nevertheless, I updated the patch to send "unknown" in this
case.

> Do we really need a test for this?

I wrote the test after Stefan's implicit request.  I'm OK with not having
a test.

> I suppose it's good practice, but
> seems a but too much.  We could put this check in some other "basic"
> test, save a bit of time.

I've updated the patch.  It now extends another test.

[0001-Eglot-Send-clientInfo-during-the-initialize-request.patch (text/x-diff, attachment)]

Message #14 received at 62198 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Felician Nemeth <felician.nemeth <at> gmail.com>
Cc: 62198 <at> debbugs.gnu.org,
 João Távora <joaotavora <at> gmail.com>
Subject: Re: bug#62198: [PATCH] Eglot: Send clientInfo during the initialize
 request
Date: Fri, 17 Mar 2023 09:25:21 +0100

Felician Nemeth <felician.nemeth <at> gmail.com> writes:

Hi Felician,

> I haven't found the prior art for this.  trampver.el repeats the header
> info, so when the version changes it should be updated two places, which
> (I think) is an antipattern.

FTR, trampver.el is always generated from trampver.el.in in the Tramp
repository, see <https://git.savannah.gnu.org/cgit/tramp.git/plain/lisp/trampver.el.in>.

Best regards, Michael.

Message #17 received at 62198 <at> debbugs.gnu.org (full text, mbox):

From: Felician Nemeth <felician.nemeth <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 62198 <at> debbugs.gnu.org,
 João Távora <joaotavora <at> gmail.com>
Subject: Re: bug#62198: [PATCH] Eglot: Send clientInfo during the initialize
 request
Date: Sun, 19 Mar 2023 13:15:24 +0100

Hi Michael,

> FTR, trampver.el is always generated from trampver.el.in in the Tramp
> repository, see <https://git.savannah.gnu.org/cgit/tramp.git/plain/lisp/trampver.el.in>.

Ah, okay, sorry.

At any rate, I think a Makefile would be an overkill for this little
feature.  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.

Message #20 received at 62198 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: Felician Nemeth <felician.nemeth <at> gmail.com>
Cc: 62198 <at> debbugs.gnu.org, Michael Albinus <michael.albinus <at> gmx.de>
Subject: Re: bug#62198: [PATCH] Eglot: Send clientInfo during the initialize
 request
Date: Sun, 19 Mar 2023 13:23:29 +0000

On Sun, Mar 19, 2023 at 12:15 PM Felician Nemeth
<felician.nemeth <at> gmail.com> wrote:
>
> Hi Michael,
>
> > FTR, trampver.el is always generated from trampver.el.in in the Tramp
> > repository, see <https://git.savannah.gnu.org/cgit/tramp.git/plain/lisp/trampver.el.in>.
>
> Ah, okay, sorry.
>
> At any rate, I think a Makefile would be an overkill for this little
> feature.

FWIW, my other SLY extension also has a complicated "scan own file"
thing.  Known to not work extremely well/be very useful...

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

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

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

João

Message #23 received at 62198 <at> debbugs.gnu.org (full text, mbox):

From: Felician Nemeth <felician.nemeth <at> gmail.com>
To: João Távora <joaotavora <at> gmail.com>
Cc: 62198 <at> debbugs.gnu.org, Michael Albinus <michael.albinus <at> gmx.de>
Subject: Re: bug#62198: [PATCH] Eglot: Send clientInfo during the initialize
 request
Date: Wed, 22 Mar 2023 17:05:08 +0100

[Message part 1 (text/plain, inline)]

>> 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 (text/x-diff, attachment)]

Message #26 received at 62198 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: Felician Nemeth <felician.nemeth <at> gmail.com>
Cc: 62198 <at> debbugs.gnu.org, Michael Albinus <michael.albinus <at> gmx.de>
Subject: Re: bug#62198: [PATCH] Eglot: Send clientInfo during the initialize
 request
Date: Wed, 22 Mar 2023 18:40:06 +0000

Felician Nemeth <felician.nemeth <at> gmail.com> writes:

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

I'm not asking you :-) These are questions I ask myself when facing bug
reports.  And usually I don't have a good way of answering except for
drilling the bug reporter.

I agree this most of this information shouldn't probably be sent over to
the server.

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

Yes, of course.  It's debugging information.  Currently the manual
advises users to list the files in 'package-user-dir', which is a really
poor way of telling the versions of ELPA packages, but it's the best
I've come up with.  What I meant is I'd like to have a way to produce a
listing of packages (required and optional, like
markdown/company/yasnippet) for inclusion in bug reports.

>> 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, I've pushed it to master.

João

Message #29 received at 62198 <at> debbugs.gnu.org (full text, mbox):

From: Felician Nemeth <felician.nemeth <at> gmail.com>
To: João Távora <joaotavora <at> gmail.com>
Cc: 62198 <at> debbugs.gnu.org
Subject: Re: bug#62198: [PATCH] Eglot: Send clientInfo during the initialize
 request
Date: Thu, 23 Mar 2023 17:03:40 +0100

> Currently the manual advises users to list the files in
> 'package-user-dir', which is a really poor way of telling the versions
> of ELPA packages, but it's the best I've come up with.  What I meant
> is I'd like to have a way to produce a listing of packages (required
> and optional, like markdown/company/yasnippet) for inclusion in bug
> reports.

The code below might be a good starting point for this.  It is inspired
by `package-compute-transaction'.  It seems to work even with Debian's
package manager ("apt install elpa-project").  So I'd like to think that
a potential failure in the code is a sign that the bug reporter has a
non-standard installation.

(require 'find-func)
(require 'package)

(defun my-list-dependencies (packages &optional seen versions)
  "Retrun the versions of dependencies of PACKAGES.
Argument PACKAGES is a list of symbols.  SEEN, VERSION are used
internally."
  (while packages
    (let ((package (pop packages)))
      (unless (memq package seen)
        (push package seen)
        (let* ((file (condition-case error
                         (find-library-name (symbol-name package))
                       (error nil)))
               (pkg-desc (if file
                             (with-temp-buffer
                               (insert-file-contents file)
                               (package-buffer-info))
                           (if (eq package 'emacs)
                               (package-desc-create :name "emacs"
                                                    :version (version-to-list
                                                              emacs-version))
                             (package-desc-create :name (symbol-name package)
                                                  :version '(0))))))
          (push (package-desc-full-name pkg-desc) versions)
          (setq packages (append packages
                                 (mapcar #'car
                                         (package-desc-reqs pkg-desc))))))))
    versions)

(my-list-dependencies '(eglot markdown company other-optional-dependency))

Message #32 received at 62198 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: Alan Donovan <adonovan <at> google.com>, 62198 <at> debbugs.gnu.org, 
 Felician Nemeth <felician.nemeth <at> gmail.com>
Subject: Re: eglot feature request: set Initialize.ClientInfo.{Name,Version}
Date: Wed, 28 Jun 2023 22:02:40 +0100

On Wed, Jun 28, 2023 at 9:41 PM Alan Donovan <adonovan <at> google.com> wrote:

> > >Hi João,
> > > would you mind making eglot populate the clientInfo.{name,version}
> > > fields of the Initialize request parameters? All that's necessary is
> > > the one-line change below, though I'm sure you know a cleaner way to
> > >express the JSON literal and the version constant.
> > No I wouldn't mind.
> Great!   I found that this expression works for the version, assuming
> eglot is actually installed:
>
>  (package-desc-version (cadr (assoc 'eglot package-alist)))

That's the thing.  Sometimes it is installed in that variable, sometimes
it's a builtin described in some other variable.  There is, I think,
a library for this.

I've found the bug thread: bug#62198.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62198

Taking the liberty of CCing there. Felicián was also looking for this.

João

Message #35 received at 62198 <at> debbugs.gnu.org (full text, mbox):

From: Felician Nemeth <felician.nemeth <at> gmail.com>
To: João Távora <joaotavora <at> gmail.com>
Cc: 62198 <at> debbugs.gnu.org, Alan Donovan <adonovan <at> google.com>
Subject: Re: eglot feature request: set Initialize.ClientInfo.{Name,Version}
Date: Thu, 29 Jun 2023 17:46:37 +0200

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

> On Wed, Jun 28, 2023 at 9:41 PM Alan Donovan <adonovan <at> google.com> wrote:
>
>> > >Hi João,
>> > > would you mind making eglot populate the clientInfo.{name,version}
>> > > fields of the Initialize request parameters? All that's necessary is
>> > > the one-line change below, though I'm sure you know a cleaner way to
>> > >express the JSON literal and the version constant.
>> > No I wouldn't mind.
>> Great!   I found that this expression works for the version, assuming
>> eglot is actually installed:
>>
>>  (package-desc-version (cadr (assoc 'eglot package-alist)))
>
> That's the thing.  Sometimes it is installed in that variable, sometimes
> it's a builtin described in some other variable.  There is, I think,
> a library for this.
>
> I've found the bug thread: bug#62198.
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62198
>
> Taking the liberty of CCing there. Felicián was also looking for this.

If Eglot is installed, then it is byte-compiled as well.  The earlier
patch in this bug report made sure that the helper library ('lisp-mnt)
was required only at compile time.  However, the patch worked even if
Eglot was not installed with package.el (but Eglot still needed to be
byte-compiled).

On the other hand, if package-desc-version is acceptable as opposed to
that earlier patch, then it is probably better than not sending a
version number in clientInfo.

Message #38 received at 62198 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: Felician Nemeth <felician.nemeth <at> gmail.com>
Cc: 62198 <at> debbugs.gnu.org, Alan Donovan <adonovan <at> google.com>
Subject: Re: eglot feature request: set Initialize.ClientInfo.{Name,Version}
Date: Thu, 29 Jun 2023 17:02:44 +0100

On Thu, Jun 29, 2023 at 4:46 PM Felician Nemeth
<felician.nemeth <at> gmail.com> wrote:
>
> João Távora <joaotavora <at> gmail.com> writes:
>
> > On Wed, Jun 28, 2023 at 9:41 PM Alan Donovan <adonovan <at> google.com> wrote:
> >
> >> > >Hi João,
> >> > > would you mind making eglot populate the clientInfo.{name,version}
> >> > > fields of the Initialize request parameters? All that's necessary is
> >> > > the one-line change below, though I'm sure you know a cleaner way to
> >> > >express the JSON literal and the version constant.
> >> > No I wouldn't mind.
> >> Great!   I found that this expression works for the version, assuming
> >> eglot is actually installed:
> >>
> >>  (package-desc-version (cadr (assoc 'eglot package-alist)))
> >
> > That's the thing.  Sometimes it is installed in that variable, sometimes
> > it's a builtin described in some other variable.  There is, I think,
> > a library for this.
> >
> > I've found the bug thread: bug#62198.
> >
> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62198
> >
> > Taking the liberty of CCing there. Felicián was also looking for this.
>
> If Eglot is installed, then it is byte-compiled as well.  The earlier
> patch in this bug report made sure that the helper library ('lisp-mnt)
> was required only at compile time.  However, the patch worked even if
> Eglot was not installed with package.el (but Eglot still needed to be
> byte-compiled).
>
> On the other hand, if package-desc-version is acceptable as opposed to
> that earlier patch, then it is probably better than not sending a
> version number in clientInfo.

I thinkt the lisp-mnt-at-compile-time solution is preferable, as I'm
not sure 'eglot always lives in package-alist (sometimes it is a
built-in and that is a royal pain).  Can you show an
updated patch for it, when you have time, Felicián?

João

Message #41 received at 62198 <at> debbugs.gnu.org (full text, mbox):

From: Felician Nemeth <felician.nemeth <at> gmail.com>
To: João Távora <joaotavora <at> gmail.com>
Cc: 62198 <at> debbugs.gnu.org, Alan Donovan <adonovan <at> google.com>
Subject: Re: eglot feature request: set Initialize.ClientInfo.{Name,Version}
Date: Sat, 15 Jul 2023 12:18:11 +0200

[Message part 1 (text/plain, inline)]

>> If Eglot is installed, then it is byte-compiled as well.  The earlier
>> patch in this bug report made sure that the helper library ('lisp-mnt)
>> was required only at compile time.  However, the patch worked even if
>> Eglot was not installed with package.el (but Eglot still needed to be
>> byte-compiled).

> I thinkt the lisp-mnt-at-compile-time solution is preferable, as I'm
> not sure 'eglot always lives in package-alist (sometimes it is a
> built-in and that is a royal pain).  Can you show an
> updated patch for it, when you have time, Felicián?

I've attached the updated patch.

[0001-Eglot-send-version-in-clientInfo-bug-62198.patch (text/x-diff, attachment)]

Message #44 received at 62198 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: joaotavora <at> gmail.com, Felician Nemeth <felician.nemeth <at> gmail.com>
Cc: 62198 <at> debbugs.gnu.org, adonovan <at> google.com
Subject: Re: bug#62198: eglot feature request: set Initialize.ClientInfo.{Name, 
 Version}
Date: Thu, 03 Aug 2023 10:39:58 +0300

> Cc: 62198 <at> debbugs.gnu.org, Alan Donovan <adonovan <at> google.com>
> From: Felician Nemeth <felician.nemeth <at> gmail.com>
> Date: Sat, 15 Jul 2023 12:18:11 +0200
> 
> >> If Eglot is installed, then it is byte-compiled as well.  The earlier
> >> patch in this bug report made sure that the helper library ('lisp-mnt)
> >> was required only at compile time.  However, the patch worked even if
> >> Eglot was not installed with package.el (but Eglot still needed to be
> >> byte-compiled).
> 
> > I thinkt the lisp-mnt-at-compile-time solution is preferable, as I'm
> > not sure 'eglot always lives in package-alist (sometimes it is a
> > built-in and that is a royal pain).  Can you show an
> > updated patch for it, when you have time, Felicián?
> 
> I've attached the updated patch.

Ping!  João, how should we proceed with this issue?

Thanks.

Message #47 received at 62198 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 62198 <at> debbugs.gnu.org, Felician Nemeth <felician.nemeth <at> gmail.com>,
 adonovan <at> google.com
Subject: Re: bug#62198: eglot feature request: set Initialize.ClientInfo.{Name, 
 Version}
Date: Thu, 3 Aug 2023 11:15:50 +0100

Sorry,

I think Felicián's patch looks good, and we should push it to master.

João

On Thu, Aug 3, 2023 at 8:39 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > Cc: 62198 <at> debbugs.gnu.org, Alan Donovan <adonovan <at> google.com>
> > From: Felician Nemeth <felician.nemeth <at> gmail.com>
> > Date: Sat, 15 Jul 2023 12:18:11 +0200
> >
> > >> If Eglot is installed, then it is byte-compiled as well.  The earlier
> > >> patch in this bug report made sure that the helper library ('lisp-mnt)
> > >> was required only at compile time.  However, the patch worked even if
> > >> Eglot was not installed with package.el (but Eglot still needed to be
> > >> byte-compiled).
> >
> > > I thinkt the lisp-mnt-at-compile-time solution is preferable, as I'm
> > > not sure 'eglot always lives in package-alist (sometimes it is a
> > > built-in and that is a royal pain).  Can you show an
> > > updated patch for it, when you have time, Felicián?
> >
> > I've attached the updated patch.
>
> Ping!  João, how should we proceed with this issue?
>
> Thanks.



-- 
João Távora

Message #52 received at 62198-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: João Távora <joaotavora <at> gmail.com>
Cc: 62198-done <at> debbugs.gnu.org, felician.nemeth <at> gmail.com, adonovan <at> google.com
Subject: Re: bug#62198: eglot feature request: set Initialize.ClientInfo.{Name, 
 Version}
Date: Thu, 03 Aug 2023 13:20:20 +0300

> From: João Távora <joaotavora <at> gmail.com>
> Date: Thu, 3 Aug 2023 11:15:50 +0100
> Cc: Felician Nemeth <felician.nemeth <at> gmail.com>, 62198 <at> debbugs.gnu.org, adonovan <at> google.com
> 
> Sorry,
> 
> I think Felicián's patch looks good, and we should push it to master.

Thanks, done, and closing the bug.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.