GNU bug report logs - #73279
[PATCH] Eglot: use immediate-mode eglot--request for :completionItem/resolve

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 73279 in the body.
You can then email your comments to 73279 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: Brennan Vincent <brennan <at> umanwizard.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Eglot: use immediate-mode eglot--request for
 :completionItem/resolve
Date: Sun, 15 Sep 2024 15:22:05 -0400

* lisp/progmodes/eglot.el: use immediate-mode eglot--request for
:completionItem/resolve in eglot-completion-at-point.

With the previous behavior, we are informing the language server of the
modified state of the buffer after initially inserting the completion,
but before fully resolving the completion item.

This confuses rust-analyzer (and maybe others, I don't know) and causes
it not to return the correct set of additionalTextEdits.

A simple Rust program that reveals the issue follows. Put the point
after HashSet and attempt to complete. With the previous behavior, the
language server fails to tell us to insert "use
std::collections::HashSet" at the top of the file. With the new behavior
as of this commit, completion works successfully (as it did in emacs
29.4).

struct S<T> {
    x: T
}

impl<T> S<HashSet<T>> {
}

fn main() {}
---
 lisp/progmodes/eglot.el | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el
index 82e99a2c920..e9de099d2cd 100644
--- a/lisp/progmodes/eglot.el
+++ b/lisp/progmodes/eglot.el
@@ -3229,7 +3229,9 @@ eglot-completion-at-point
                                                         :resolveProvider)
                                  (plist-get lsp-comp :data))
                             (eglot--request server :completionItem/resolve
-                                            lsp-comp :cancel-on-input t)
+                                            lsp-comp
+                                            :cancel-on-input t
+                                            :immediate t)
                           lsp-comp))))))
       (when (and (consp eglot--capf-session)
                  (= (car bounds) (car (nth 0 eglot--capf-session)))
-- 
2.45.2

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Brennan Vincent <brennan <at> umanwizard.com>, João Távora <joaotavora <at> gmail.com>
Cc: 73279 <at> debbugs.gnu.org
Subject: Re: bug#73279: [PATCH] Eglot: use immediate-mode eglot--request for
 :completionItem/resolve
Date: Mon, 16 Sep 2024 14:28:38 +0300

> From: Brennan Vincent <brennan <at> umanwizard.com>
> Date: Sun, 15 Sep 2024 15:22:05 -0400
> 
> * lisp/progmodes/eglot.el: use immediate-mode eglot--request for
> :completionItem/resolve in eglot-completion-at-point.
> 
> With the previous behavior, we are informing the language server of the
> modified state of the buffer after initially inserting the completion,
> but before fully resolving the completion item.
> 
> This confuses rust-analyzer (and maybe others, I don't know) and causes
> it not to return the correct set of additionalTextEdits.
> 
> A simple Rust program that reveals the issue follows. Put the point
> after HashSet and attempt to complete. With the previous behavior, the
> language server fails to tell us to insert "use
> std::collections::HashSet" at the top of the file. With the new behavior
> as of this commit, completion works successfully (as it did in emacs
> 29.4).
> 
> struct S<T> {
>     x: T
> }
> 
> impl<T> S<HashSet<T>> {
> }
> 
> fn main() {}
> ---
>  lisp/progmodes/eglot.el | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el
> index 82e99a2c920..e9de099d2cd 100644
> --- a/lisp/progmodes/eglot.el
> +++ b/lisp/progmodes/eglot.el
> @@ -3229,7 +3229,9 @@ eglot-completion-at-point
>                                                          :resolveProvider)
>                                   (plist-get lsp-comp :data))
>                              (eglot--request server :completionItem/resolve
> -                                            lsp-comp :cancel-on-input t)
> +                                            lsp-comp
> +                                            :cancel-on-input t
> +                                            :immediate t)
>                            lsp-comp))))))
>        (when (and (consp eglot--capf-session)
>                   (= (car bounds) (car (nth 0 eglot--capf-session)))
> -- 
> 2.45.2

João, any comments?

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

From: João Távora <joaotavora <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Brennan Vincent <brennan <at> umanwizard.com>, 73279 <at> debbugs.gnu.org
Subject: Re: bug#73279: [PATCH] Eglot: use immediate-mode eglot--request for
 :completionItem/resolve
Date: Mon, 16 Sep 2024 14:43:31 +0100

On Mon, Sep 16, 2024 at 12:28 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Brennan Vincent <brennan <at> umanwizard.com>
> > Date: Sun, 15 Sep 2024 15:22:05 -0400

> João, any comments?

Yes, I have yet to try the reproduction recipe of this alleged problem
but one thing stands out.  Brennan, you wrote "as  it did in Emacs 29.4".
So this is a recent regression of sorts, is that what you're saying?  I don't
think that code has changed much over the past years.

I also don't recognize the timing you're describing, but I'll comment
on that after I've done my investigation.  Usually there's a low
chance a patch will easily go through in this very sensitive area
of the code.   But a low change is nonetheless non-0 :-)  Maybe
Dmitry can also have a look, as he's been tinkering with Eglot
completion lately.

João Távora

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

From: "Brennan Vincent" <brennan <at> umanwizard.com>
To: João Távora <joaotavora <at> gmail.com>, Eli Zaretskii
 <eliz <at> gnu.org>, Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 73279 <at> debbugs.gnu.org
Subject: Re: bug#73279: [PATCH] Eglot: use immediate-mode eglot--request for
 :completionItem/resolve
Date: Mon, 16 Sep 2024 11:17:05 -0400

Hi João,

Just in case you're not familiar with Rust, here are the detailed repro
instructions:

1. Install rust, cargo, and rust-analyzer: https://rustup.rs
2. Create a new project: cargo new my-project
3. Paste the repro recipe from my patch commit message into
my-project/src/main.rs

As for the regression: yes, it's a regression from 29.4, and in fact I
have bisected to the commit that regressed it:
a8c1559a663d9bc21776e33303251e244f86f0d7

So this is broken for me in both 30 and 31.

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

> On Mon, Sep 16, 2024 at 12:28 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>>
>> > From: Brennan Vincent <brennan <at> umanwizard.com>
>> > Date: Sun, 15 Sep 2024 15:22:05 -0400
>
>> João, any comments?
>
> Yes, I have yet to try the reproduction recipe of this alleged problem
> but one thing stands out.  Brennan, you wrote "as  it did in Emacs 29.4".
> So this is a recent regression of sorts, is that what you're saying?  I don't
> think that code has changed much over the past years.
>
> I also don't recognize the timing you're describing, but I'll comment
> on that after I've done my investigation.  Usually there's a low
> chance a patch will easily go through in this very sensitive area
> of the code.   But a low change is nonetheless non-0 :-)  Maybe
> Dmitry can also have a look, as he's been tinkering with Eglot
> completion lately.
>
> João Távora

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

From: João Távora <joaotavora <at> gmail.com>
To: Brennan Vincent <brennan <at> umanwizard.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 73279 <at> debbugs.gnu.org,
 Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#73279: [PATCH] Eglot: use immediate-mode eglot--request for
 :completionItem/resolve
Date: Mon, 16 Sep 2024 16:40:01 +0100

On Mon, Sep 16, 2024 at 4:17 PM Brennan Vincent <brennan <at> umanwizard.com> wrote:

> As for the regression: yes, it's a regression from 29.4, and in fact I
> have bisected to the commit that regressed it:
> a8c1559a663d9bc21776e33303251e244f86f0d7

Oh alright, that clears it up.  It was an oversight indeed, so I think
your patch is TRT.  I'll install it in emacs-30.

João

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

From: João Távora <joaotavora <at> gmail.com>
To: Brennan Vincent <brennan <at> umanwizard.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 73279 <at> debbugs.gnu.org,
 Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#73279: [PATCH] Eglot: use immediate-mode eglot--request for
 :completionItem/resolve
Date: Mon, 16 Sep 2024 16:50:35 +0100

On Mon, Sep 16, 2024 at 4:40 PM João Távora <joaotavora <at> gmail.com> wrote:
>
> On Mon, Sep 16, 2024 at 4:17 PM Brennan Vincent <brennan <at> umanwizard.com> wrote:
>
> > As for the regression: yes, it's a regression from 29.4, and in fact I
> > have bisected to the commit that regressed it:
> > a8c1559a663d9bc21776e33303251e244f86f0d7
>
> Oh alright, that clears it up.  It was an oversight indeed, so I think
> your patch is TRT.  I'll install it in emacs-30.

Actually, not so fast.  The code before that allegedly broken commit
_also_ sent outstanding changes to the server before resolving
(via the advice that was then removed).

So I must be missing something, and must investigate more
closely.

João

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

From: João Távora <joaotavora <at> gmail.com>
To: Brennan Vincent <brennan <at> umanwizard.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 73279 <at> debbugs.gnu.org,
 Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#73279: [PATCH] Eglot: use immediate-mode eglot--request for
 :completionItem/resolve
Date: Mon, 16 Sep 2024 17:21:21 +0100

On Mon, Sep 16, 2024 at 4:50 PM João Távora <joaotavora <at> gmail.com> wrote:
>
> On Mon, Sep 16, 2024 at 4:40 PM João Távora <joaotavora <at> gmail.com> wrote:
> >
> > On Mon, Sep 16, 2024 at 4:17 PM Brennan Vincent <brennan <at> umanwizard.com> wrote:
> >
> > > As for the regression: yes, it's a regression from 29.4, and in fact I
> > > have bisected to the commit that regressed it:
> > > a8c1559a663d9bc21776e33303251e244f86f0d7
> >
> > Oh alright, that clears it up.  It was an oversight indeed, so I think
> > your patch is TRT.  I'll install it in emacs-30.
>
> Actually, not so fast.  The code before that allegedly broken commit
> _also_ sent outstanding changes to the server before resolving
> (via the advice that was then removed).
>
> So I must be missing something, and must investigate more
> closely.

Brennan, can you provide an excerpt of the Eglot event log
(M-x eglot-events-buffer) for your MRE recipe before and
after a8c1559a663d9bc21776e33303251e244f86f0d7?

It should highlight what has changed in the client-server
communication, if anything.

João

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

From: "Brennan Vincent" <brennan <at> umanwizard.com>
To: João Távora <joaotavora <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 73279 <at> debbugs.gnu.org,
 Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#73279: [PATCH] Eglot: use immediate-mode eglot--request for
 :completionItem/resolve
Date: Mon, 16 Sep 2024 13:06:55 -0400

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

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

> On Mon, Sep 16, 2024 at 4:50 PM João Távora <joaotavora <at> gmail.com> wrote:
>>
>> On Mon, Sep 16, 2024 at 4:40 PM João Távora <joaotavora <at> gmail.com> wrote:
>> >
>> > On Mon, Sep 16, 2024 at 4:17 PM Brennan Vincent <brennan <at> umanwizard.com> wrote:
>> >
>> > > As for the regression: yes, it's a regression from 29.4, and in fact I
>> > > have bisected to the commit that regressed it:
>> > > a8c1559a663d9bc21776e33303251e244f86f0d7
>> >
>> > Oh alright, that clears it up.  It was an oversight indeed, so I think
>> > your patch is TRT.  I'll install it in emacs-30.
>>
>> Actually, not so fast.  The code before that allegedly broken commit
>> _also_ sent outstanding changes to the server before resolving
>> (via the advice that was then removed).

Not according to my testing.

And, taking a look at the old code:

(advice-add #'jsonrpc-request :before
            (cl-function (lambda (_proc _method _params &key
                                        deferred &allow-other-keys)
                           (when (and eglot--managed-mode deferred)
                             (eglot--signal-textDocument/didChange))))
            '((name . eglot--signal-textDocument/didChange)))

It seems that we are only sending the changes if the function is called
with the :deferred flag. The function was NOT called with the :deferred
flag at the site in question, which as of 093a36 (parent of a8c1559)
looked like this:

(jsonrpc-request server :completionItem/resolve
                 lsp-comp :cancel-on-input t)

>>
>> So I must be missing something, and must investigate more
>> closely.
>
> Brennan, can you provide an excerpt of the Eglot event log
> (M-x eglot-events-buffer) for your MRE recipe before and
> after a8c1559a663d9bc21776e33303251e244f86f0d7?
>

Sure. See attachments. They are a bit long because of the huge doc
strings rust-analyzer includes, but you should get the idea by searching
for textDocument/completion.

Note that in BEFORE, we send textDocument/completion, immediately followed by
completionItem/resolve. In AFTER, we send textDocument/completion, then
textDocument/didChange, then completionItem/resolve.

[BEFORE (text/plain, attachment)]

[AFTER (text/plain, attachment)]

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

> It should highlight what has changed in the client-server
> communication, if anything.
>
> João

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

From: "Brennan Vincent" <brennan <at> umanwizard.com>
To: João Távora <joaotavora <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 73279 <at> debbugs.gnu.org,
 Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#73279: [PATCH] Eglot: use immediate-mode eglot--request for
 :completionItem/resolve
Date: Wed, 25 Sep 2024 11:14:07 -0400

Hi João,

Did you get a chance to take a look at my last message? Let me know if I
need to provide any further information.

Thanks
Brennan

"Brennan Vincent" <brennan <at> umanwizard.com> writes:

> João Távora <joaotavora <at> gmail.com> writes:
>
>> On Mon, Sep 16, 2024 at 4:50 PM João Távora <joaotavora <at> gmail.com> wrote:
>>>
>>> On Mon, Sep 16, 2024 at 4:40 PM João Távora <joaotavora <at> gmail.com> wrote:
>>> >
>>> > On Mon, Sep 16, 2024 at 4:17 PM Brennan Vincent <brennan <at> umanwizard.com> wrote:
>>> >
>>> > > As for the regression: yes, it's a regression from 29.4, and in fact I
>>> > > have bisected to the commit that regressed it:
>>> > > a8c1559a663d9bc21776e33303251e244f86f0d7
>>> >
>>> > Oh alright, that clears it up.  It was an oversight indeed, so I think
>>> > your patch is TRT.  I'll install it in emacs-30.
>>>
>>> Actually, not so fast.  The code before that allegedly broken commit
>>> _also_ sent outstanding changes to the server before resolving
>>> (via the advice that was then removed).
>
> Not according to my testing.
>
> And, taking a look at the old code:
>
> (advice-add #'jsonrpc-request :before
>             (cl-function (lambda (_proc _method _params &key
>                                         deferred &allow-other-keys)
>                            (when (and eglot--managed-mode deferred)
>                              (eglot--signal-textDocument/didChange))))
>             '((name . eglot--signal-textDocument/didChange)))
>
> It seems that we are only sending the changes if the function is called
> with the :deferred flag. The function was NOT called with the :deferred
> flag at the site in question, which as of 093a36 (parent of a8c1559)
> looked like this:
>
> (jsonrpc-request server :completionItem/resolve
>                  lsp-comp :cancel-on-input t)
>
>>>
>>> So I must be missing something, and must investigate more
>>> closely.
>>
>> Brennan, can you provide an excerpt of the Eglot event log
>> (M-x eglot-events-buffer) for your MRE recipe before and
>> after a8c1559a663d9bc21776e33303251e244f86f0d7?
>>
>
> Sure. See attachments. They are a bit long because of the huge doc
> strings rust-analyzer includes, but you should get the idea by searching
> for textDocument/completion.
>
> Note that in BEFORE, we send textDocument/completion, immediately followed by
> completionItem/resolve. In AFTER, we send textDocument/completion, then
> textDocument/didChange, then completionItem/resolve.
>
> (snip)
>
>> It should highlight what has changed in the client-server
>> communication, if anything.
>>
>> João

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

From: João Távora <joaotavora <at> gmail.com>
To: Brennan Vincent <brennan <at> umanwizard.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 73279 <at> debbugs.gnu.org,
 Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#73279: [PATCH] Eglot: use immediate-mode eglot--request for
 :completionItem/resolve
Date: Thu, 26 Sep 2024 11:27:29 +0100

On Wed, Sep 25, 2024 at 4:14 PM Brennan Vincent <brennan <at> umanwizard.com> wrote:
>
> Hi João,
>
> Did you get a chance to take a look at my last message? Let me know if I
> need to provide any further information.
>
> Thanks
> Brennan

Sorry, Brennan, this slipped through the cracks.  I'm 99% sure your
patch is the right
thing, but I haven't had time to test it properly.  I think we should
push it.  To emacs-30?
Or to master?  I'd say emacs-30, but someone let me know if that's closed now
or something like that.

João

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: João Távora <joaotavora <at> gmail.com>
Cc: brennan <at> umanwizard.com, 73279 <at> debbugs.gnu.org, dgutov <at> yandex.ru
Subject: Re: bug#73279: [PATCH] Eglot: use immediate-mode eglot--request for
 :completionItem/resolve
Date: Thu, 26 Sep 2024 13:58:07 +0300

> From: João Távora <joaotavora <at> gmail.com>
> Date: Thu, 26 Sep 2024 11:27:29 +0100
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Dmitry Gutov <dgutov <at> yandex.ru>, 73279 <at> debbugs.gnu.org
> 
> On Wed, Sep 25, 2024 at 4:14 PM Brennan Vincent <brennan <at> umanwizard.com> wrote:
> >
> > Hi João,
> >
> > Did you get a chance to take a look at my last message? Let me know if I
> > need to provide any further information.
> >
> > Thanks
> > Brennan
> 
> Sorry, Brennan, this slipped through the cracks.  I'm 99% sure your
> patch is the right
> thing, but I haven't had time to test it properly.  I think we should
> push it.  To emacs-30?
> Or to master?  I'd say emacs-30, but someone let me know if that's closed now
> or something like that.

emacs-30 is okay for this patch, thanks.

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

From: "Brennan Vincent" <brennan <at> umanwizard.com>
To: Eli Zaretskii <eliz <at> gnu.org>, João Távora
 <joaotavora <at> gmail.com>
Cc: 73279 <at> debbugs.gnu.org, dgutov <at> yandex.ru
Subject: Re: bug#73279: [PATCH] Eglot: use immediate-mode eglot--request for
 :completionItem/resolve
Date: Sun, 06 Oct 2024 13:13:52 +0100

Hi all,

Looks like this still hasn't been pushed to emacs-30 as of today.

Thanks
Brennan

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: João Távora <joaotavora <at> gmail.com>
>> Date: Thu, 26 Sep 2024 11:27:29 +0100
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, Dmitry Gutov <dgutov <at> yandex.ru>, 73279 <at> debbugs.gnu.org
>> 
>> On Wed, Sep 25, 2024 at 4:14 PM Brennan Vincent <brennan <at> umanwizard.com> wrote:
>> >
>> > Hi João,
>> >
>> > Did you get a chance to take a look at my last message? Let me know if I
>> > need to provide any further information.
>> >
>> > Thanks
>> > Brennan
>> 
>> Sorry, Brennan, this slipped through the cracks.  I'm 99% sure your
>> patch is the right
>> thing, but I haven't had time to test it properly.  I think we should
>> push it.  To emacs-30?
>> Or to master?  I'd say emacs-30, but someone let me know if that's closed now
>> or something like that.
>
> emacs-30 is okay for this patch, thanks.

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

From: João Távora <joaotavora <at> gmail.com>
To: Brennan Vincent <brennan <at> umanwizard.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 73279 <at> debbugs.gnu.org, dgutov <at> yandex.ru
Subject: Re: bug#73279: [PATCH] Eglot: use immediate-mode eglot--request for
 :completionItem/resolve
Date: Wed, 9 Oct 2024 12:50:03 +0100

On Sun, Oct 6, 2024 at 1:14 PM Brennan Vincent <brennan <at> umanwizard.com> wrote:
>
> Hi all,
>
> Looks like this still hasn't been pushed to emacs-30 as of today.

Sorry Brennan this delay was my bad again.  I found a bit of time today and
I just pushed your patch.

João

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

From: "Brennan Vincent" <brennan <at> umanwizard.com>
To: João Távora <joaotavora <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 73279 <at> debbugs.gnu.org, dgutov <at> yandex.ru
Subject: Re: bug#73279: [PATCH] Eglot: use immediate-mode eglot--request for
 :completionItem/resolve
Date: Wed, 09 Oct 2024 08:12:01 -0400

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

> On Sun, Oct 6, 2024 at 1:14 PM Brennan Vincent <brennan <at> umanwizard.com> wrote:
>>
>> Hi all,
>>
>> Looks like this still hasn't been pushed to emacs-30 as of today.
>
> Sorry Brennan this delay was my bad again.  I found a bit of time today and
> I just pushed your patch.
>
> João

Thanks!

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Brennan Vincent <brennan <at> umanwizard.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, dgutov <at> yandex.ru,
 João Távora <joaotavora <at> gmail.com>,
 73279-done <at> debbugs.gnu.org
Subject: Re: bug#73279: [PATCH] Eglot: use immediate-mode eglot--request for
 :completionItem/resolve
Date: Thu, 13 Feb 2025 02:28:51 -0800

"Brennan Vincent" <brennan <at> umanwizard.com> writes:

> João Távora <joaotavora <at> gmail.com> writes:
>
>> On Sun, Oct 6, 2024 at 1:14 PM Brennan Vincent <brennan <at> umanwizard.com> wrote:
>>>
>>> Hi all,
>>>
>>> Looks like this still hasn't been pushed to emacs-30 as of today.
>>
>> Sorry Brennan this delay was my bad again.  I found a bit of time today and
>> I just pushed your patch.
>>
>> João
>
> Thanks!

It seems like the patch was pushed, so I'm closing this bug report now.

Previous Next

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