bug#81514: 32.0.50; Eglot messages progress reporter shows errors
Stéphane Marks <[email protected]> Tue, 4 Aug 2026 21:50:50 +0200
| Newsgroups | gmane.emacs.bugs |
|---|---|
| Message-ID | <CAN+1HbqJ79KnnuSDYX7W5GOWGSeA4g021U9A8SQPBsDGy=XVdA@mail.gmail.com> |
--0000000000007b6f3806583df914
Content-Type: multipart/alternative; boundary="0000000000007b6f3606583df912"
--0000000000007b6f3606583df912
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
The attached patch still needs to be installed, I think on the release
branch. I'd closed this issue prematurely thinking it was just the eglot
component that Joao took care of.
On Wed, Jul 29, 2026 at 3:33=E2=80=AFPM St=C3=A9phane Marks <shipmints@gmai=
l.com> wrote:
> On Wed, Jul 29, 2026 at 2:47=E2=80=AFPM St=C3=A9phane Marks <shipmints@gm=
ail.com>
> wrote:
>
>> On Wed, Jul 29, 2026 at 11:17=E2=80=AFAM Jacek =C5=9Awierk <jacekswierk@=
gmail.com>
>> wrote:
>>
>>> I can reproduce it with clangd on the following C++ repository:
>>> https://github.com/rui314/mold. It doesn't happen every time but often
>>> enough:
>>>
>>> Debugger entered--Lisp error: (wrong-type-argument sequencep 100)
>>> ((20 . [1785337541.907988 nil nil "[eglot] mold
>>> backgroundIndexProgress: indexing..." 1 0.2 nil nil]) 20 100)
>>> progress-reporter-do-update((20 . [1785337541.907988 nil nil "[eglot]
>>> mold backgroundIndexProgress: indexing..." 1 0.2 nil nil]) 100 nil)
>>> eglot--reporter-update((20 . [1785337541.907988 nil nil "[eglot] mold
>>> backgroundIndexProgress: indexing..." 1 0.2 nil nil]) 100 nil)
>>> #f(compiled-function (arg1 arg2 arg3 arg4 &rest rest) #<bytecode
>>> 0xa1216d65848076a>)(#<eglot-lsp-server 1022b7360904>
>>> "backgroundIndexProgress" 100 nil)
>>> #f(compiled-function (arg1 arg2 &rest rest) "Handle $/progress
>>> notification identified by TOKEN from SERVER." #<bytecode
>>> -0xf68beacb9f43862>)(#<eglot-lsp-server 1022b7360904> $/progress :token
>>> "backgroundIndexProgress" :value (:kind "end"))
>>> apply(#f(compiled-function (arg1 arg2 &rest rest) "Handle $/progress
>>> notification identified by TOKEN from SERVER." #<bytecode
>>> -0xf68beacb9f43862>) #<eglot-lsp-server 1022b7360904> $/progress (:toke=
n
>>> "backgroundIndexProgress" :value (:kind "end")))
>>> eglot-handle-notification(#<eglot-lsp-server 1022b7360904> $/progress
>>> :token "backgroundIndexProgress" :value (:kind "end"))
>>> apply(eglot-handle-notification #<eglot-lsp-server 1022b7360904>
>>> $/progress (:token "backgroundIndexProgress" :value (:kind "end")))
>>> #f(compiled-function (server method params) #<bytecode
>>> 0x1f1b657efb0838aa>)(#<eglot-lsp-server 1022b7360904> $/progress (:toke=
n
>>> "backgroundIndexProgress" :value (:kind "end")))
>>> jsonrpc-connection-receive(#<eglot-lsp-server 1022b7360904> (:jsonrpc
>>> "2.0" :method "$/progress" :params (:token "backgroundIndexProgress" :v=
alue
>>> (:kind "end"))))
>>> #f(compiled-function (conn msg) #<bytecode
>>> 0x4e6153735258fd3>)(#<eglot-lsp-server 1022b7360904> (:jsonrpc "2.0"
>>> :method "$/progress" :params (:token "backgroundIndexProgress" :value
>>> (:kind "end"))))
>>> apply(#f(compiled-function (conn msg) #<bytecode 0x4e6153735258fd3>)
>>> (#<eglot-lsp-server 1022b7360904> (:jsonrpc "2.0" :method "$/progress"
>>> :params (:token "backgroundIndexProgress" :value (:kind "end")))))
>>> timer-event-handler([t 27242 5829 902968 nil #f(compiled-function
>>> (conn msg) #<bytecode 0x4e6153735258fd3>) (#<eglot-lsp-server 1022b7360=
904>
>>> (:jsonrpc "2.0" :method "$/progress" :params (:token
>>> "backgroundIndexProgress" :value (:kind "end")))) nil 894000 nil])
>>>
>>> The LSP message that causes it looks like this from the
>>> (eglot-events-buffer):
>>> <-- $/progress
>>> {"jsonrpc":"2.0","method":"$/progress","params":{"token":"backgroundInd=
exProgress","value":{"kind":"end"}}}
>>>
>>> Based on my understanding of Eglot code, Eglot creates a non-numeric
>>> progress
>>> reporter because MIN-VALUE and MAX-VALUE arguments are not provided.
>>> However, it
>>> looks like Eglot updates the created progress reporter as it were
>>> numeric:
>>> (eglot--reporter-update pr pcnt msg)
>>>
>>> For the {"kind": "end"} notification, pcnt is set to 100 and msg is nil=
.
>>> After
>>> commit b6849229003, the pulsing reporter forwards (or update-text value=
)
>>> as
>>> UPDATE-TEXT. That evaluates to 100. Then progress-reporter-echo-area
>>> tries
>>> (concat (if update-text " " "") update-text) which triggers the shown
>>> error.
>>>
>> I was able to reproduce the issue without eglot and will take a look.
>>
>> Coincidentally, and independent of the issue, eglot seems to want a
>> numeric reporter but instead creates a non-numeric reporter. eglot-hand=
le-notification
>> method seems to also be missing the call to progress-reporter-done that
>> would clear any stateful reporters it's created such as those in
>> system-taskbar for which a relevant change was made in Tramp recently. =
I
>> can take a stab at those.
>>
>
> Here's a patch for progress-reporter. I can look into eglot separately i=
f
> agreed.
>
> -St=C3=A9phane
>
--0000000000007b6f3606583df912
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:monospac=
e">The attached patch still needs to be installed,=C2=A0I think on the rele=
ase branch.=C2=A0 I'd closed this issue prematurely thinking it was jus=
t the eglot component=C2=A0that Joao took care of.</div><div class=3D"gmail=
_default" style=3D"font-family:monospace"><br></div><div class=3D"gmail_def=
ault" style=3D"font-family:monospace"><br></div></div><br><div class=3D"gma=
il_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On We=
d, Jul 29, 2026 at 3:33=E2=80=AFPM St=C3=A9phane Marks <<a href=3D"mailt=
o:[email protected]">[email protected]</a>> wrote:<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"=
><div class=3D"gmail_default" style=3D"font-family:monospace"><span style=
=3D"font-family:Arial,Helvetica,sans-serif;background-color:transparent">On=
Wed, Jul 29, 2026 at 2:47=E2=80=AFPM St=C3=A9phane Marks <<a href=3D"ma=
ilto:[email protected]" target=3D"_blank">[email protected]</a>> wro=
te:</span></div></div><div class=3D"gmail_quote"><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><div style=3D"fon=
t-family:monospace"><span style=3D"font-family:Arial,Helvetica,sans-serif;b=
ackground-color:transparent">On Wed, Jul 29, 2026 at 11:17=E2=80=AFAM Jacek=
=C5=9Awierk <<a href=3D"mailto:[email protected]" target=3D"_blank"=
>[email protected]</a>> wrote:</span></div></div><div class=3D"gmail=
_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
=20
=20
=20
<div>
<p><font face=3D"monospace">I can reproduce it with clangd on the
following C++ repository:<br>
<a href=3D"https://github.com/rui314/mold" target=3D"_blank">https:=
//github.com/rui314/mold</a>. It doesn't happen every time but
often enough:<br>
<br>
Debugger entered--Lisp error: (wrong-type-argument sequencep
100)<br>
=C2=A0 ((20 . [1785337541.907988 nil nil "[eglot] mold
backgroundIndexProgress: indexing..." 1 0.2 nil nil]) 20 100)<=
br>
=C2=A0 progress-reporter-do-update((20 . [1785337541.907988 nil nil
"[eglot] mold backgroundIndexProgress: indexing..." 1 0.2=
nil
nil]) 100 nil)<br>
=C2=A0 eglot--reporter-update((20 . [1785337541.907988 nil nil
"[eglot] mold backgroundIndexProgress: indexing..." 1 0.2=
nil
nil]) 100 nil)<br>
=C2=A0 #f(compiled-function (arg1 arg2 arg3 arg4 &rest rest)
#<bytecode 0xa1216d65848076a>)(#<eglot-lsp-server
1022b7360904> "backgroundIndexProgress" 100 nil)<br>
=C2=A0 #f(compiled-function (arg1 arg2 &rest rest) "Handle
$/progress notification identified by TOKEN from SERVER."
#<bytecode -0xf68beacb9f43862>)(#<eglot-lsp-server
1022b7360904> $/progress :token "backgroundIndexProgress&qu=
ot;
:value (:kind "end"))<br>
=C2=A0 apply(#f(compiled-function (arg1 arg2 &rest rest) "=
Handle
$/progress notification identified by TOKEN from SERVER."
#<bytecode -0xf68beacb9f43862>) #<eglot-lsp-server
1022b7360904> $/progress (:token "backgroundIndexProgress&q=
uot;
:value (:kind "end")))<br>
=C2=A0 eglot-handle-notification(#<eglot-lsp-server
1022b7360904> $/progress :token "backgroundIndexProgress&qu=
ot;
:value (:kind "end"))<br>
=C2=A0 apply(eglot-handle-notification #<eglot-lsp-server
1022b7360904> $/progress (:token "backgroundIndexProgress&q=
uot;
:value (:kind "end")))<br>
=C2=A0 #f(compiled-function (server method params) #<bytecode
0x1f1b657efb0838aa>)(#<eglot-lsp-server 1022b7360904>
$/progress (:token "backgroundIndexProgress" :value (:kin=
d
"end")))<br>
=C2=A0 jsonrpc-connection-receive(#<eglot-lsp-server
1022b7360904> (:jsonrpc "2.0" :method "$/progress=
" :params
(:token "backgroundIndexProgress" :value (:kind "end=
"))))<br>
=C2=A0 #f(compiled-function (conn msg) #<bytecode
0x4e6153735258fd3>)(#<eglot-lsp-server 1022b7360904>
(:jsonrpc "2.0" :method "$/progress" :params (:=
token
"backgroundIndexProgress" :value (:kind "end"))=
))<br>
=C2=A0 apply(#f(compiled-function (conn msg) #<bytecode
0x4e6153735258fd3>) (#<eglot-lsp-server 1022b7360904>
(:jsonrpc "2.0" :method "$/progress" :params (:=
token
"backgroundIndexProgress" :value (:kind "end"))=
)))<br>
=C2=A0 timer-event-handler([t 27242 5829 902968 nil
#f(compiled-function (conn msg) #<bytecode
0x4e6153735258fd3>) (#<eglot-lsp-server 1022b7360904>
(:jsonrpc "2.0" :method "$/progress" :params (:=
token
"backgroundIndexProgress" :value (:kind "end"))=
)) nil 894000
nil])<br>
<br>
The LSP message that causes it looks like this from the
(eglot-events-buffer):<br>
<-- $/progress
{"jsonrpc":"2.0","method":"$/progress&qu=
ot;,"params":{"token":"backgroundIndexProgress&quo=
t;,"value":{"kind":"end"}}}<br>
<br>
Based on my understanding of Eglot code, Eglot creates a
non-numeric progress<br>
reporter because MIN-VALUE and MAX-VALUE arguments are not
provided. However, it<br>
looks like Eglot updates the created progress reporter as it
were numeric:<br>
(eglot--reporter-update pr pcnt msg)<br>
<br>
For the {"kind": "end"} notification, pcnt is s=
et to 100 and msg
is nil. After<br>
commit b6849229003, the pulsing reporter forwards (or
update-text value) as<br>
UPDATE-TEXT. That evaluates to 100. Then
progress-reporter-echo-area tries<br>
(concat (if update-text " " "") update-text) wh=
ich triggers the
shown error.</font></p></div></blockquote><div style=3D"font-family=
:monospace">I was able to reproduce the issue without eglot and will take a=
look.</div><div style=3D"font-family:monospace"><br></div><div style=3D"fo=
nt-family:monospace"><span style=3D"background-color:transparent">Coinciden=
tally, and independent of the issue,=C2=A0</span>eglot seems to want a nume=
ric reporter but instead creates a non-numeric reporter.=C2=A0=C2=A0<span s=
tyle=3D"background-color:transparent">eglot-handle-notification method</spa=
n><span style=3D"background-color:transparent">=C2=A0seems to also be missi=
ng the call to progress-reporter-done that would clear any stateful reporte=
rs it's created such as those in system-taskbar for which a relevant ch=
ange was made in Tramp recently.=C2=A0 I can take a stab at those.</span></=
div></div></div></blockquote><div><br></div><div class=3D"gmail_default" st=
yle=3D"font-family:monospace">Here's a patch for progress-reporter.=C2=
=A0 I can look into eglot separately if agreed.</div><div class=3D"gmail_de=
fault" style=3D"font-family:monospace"><br></div><div class=3D"gmail_defaul=
t" style=3D"font-family:monospace">-St=C3=A9phane=C2=A0</div></div></div>
</blockquote></div>
--0000000000007b6f3606583df912--
--0000000000007b6f3806583df914
Content-Type: application/octet-stream;
name="0001-Fix-progress-reporter-echo-area-update-text-bug-8151.patch"
Content-Disposition: attachment;
filename="0001-Fix-progress-reporter-echo-area-update-text-bug-8151.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_msf2omoa0>
X-Attachment-Id: f_msf2omoa0
RnJvbSBiYjhhNjk1OTdhMWM1MjgzODkyNmYxODU0YjM2YjRkNjM0NTVhOTU2IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/U3Q9QzM9QTlwaGFuZT0yME1hcmtzPz0gPHNo
aXBtaW50c0BnbWFpbC5jb20+CkRhdGU6IFdlZCwgMjkgSnVsIDIwMjYgMTU6MzA6NDUgLTA0MDAK
U3ViamVjdDogW1BBVENIXSBGaXggcHJvZ3Jlc3MtcmVwb3J0ZXItZWNoby1hcmVhIHVwZGF0ZS10
ZXh0IChidWcjODE1MTQpCgoqIGxpc3Avc3Vici5lbCAocHJvZ3Jlc3MtcmVwb3J0ZXItZWNoby1h
cmVhKTogRm9ybWF0IFVQREFURS1URVhUCmFzIGEgc3RyaW5nLgotLS0KIGxpc3Avc3Vici5lbCB8
IDIgKy0KIDEgZmlsZSBjaGFuZ2VkLCAxIGluc2VydGlvbigrKSwgMSBkZWxldGlvbigtKQoKZGlm
ZiAtLWdpdCBhL2xpc3Avc3Vici5lbCBiL2xpc3Avc3Vici5lbAppbmRleCBhOTkyNDQ0NWFkYS4u
YjQ2NTczOGYxMDYgMTAwNjQ0Ci0tLSBhL2xpc3Avc3Vici5lbAorKysgYi9saXNwL3N1YnIuZWwK
QEAgLTcyNDAsNyArNzI0MCw3IEBAIHByb2dyZXNzLXJlcG9ydGVyLWVjaG8tYXJlYQogICAgICh1
bmxlc3MgKGFuZCAoZXEgKHByb2dyZXNzLXJlcG9ydGVyLWNvbnRleHQgcmVwb3J0ZXIpICdhc3lu
YykKICAgICAgICAgICAgICAgICAgKGN1cnJlbnQtbWVzc2FnZSkKICAgICAgICAgICAgICAgICAg
KG5vdCAoc3RyaW5nLXByZWZpeC1wIHRleHQgKGN1cnJlbnQtbWVzc2FnZSkpKSkKLSAgICAgIChz
ZXRxIHVwZGF0ZS10ZXh0IChjb25jYXQgKGlmIHVwZGF0ZS10ZXh0ICIgIiAiIikgdXBkYXRlLXRl
eHQpKQorICAgICAgKHNldHEgdXBkYXRlLXRleHQgKGlmIHVwZGF0ZS10ZXh0IChmb3JtYXQgIiAl
cyIgdXBkYXRlLXRleHQpICIiKSkKICAgICAgIChwY2FzZSBzdGF0ZQogICAgICAgICAoKHByZWQg
ZmxvYXRwKQogICAgICAgICAgKGlmIChwbHVzcCBzdGF0ZSkKLS0gCjIuNTQuMAoK
--0000000000007b6f3806583df914--