bug#81514: 32.0.50; Eglot messages progress reporter shows errors
João Távora <[email protected]> Sat, 01 Aug 2026 13:00:12 +0100
| Newsgroups | gmane.emacs.bugs |
|---|---|
| Message-ID | <[email protected]> |
Stéphane Marks <[email protected]> writes: I've pushed my simpler patch commit cf98d9d725f034b3dd89f6f92a1c8205e778f98c Author: João Távora <[email protected]> Date: Sat Aug 1 10:54:10 2026 +0100 Eglot: do more orthodox use of progress reporters (bug#81514) The progress reporters on recent Emacs has backward incompatible changes, but our use of them wasn't too correct either. but please read on. > The previous reporter or the fixed one? And before or > after your changes? > It is good the system-taskbar progress bar displays but it is bad that > it pulses for a known 0-100 progress reporter What do you mean by "pulsing"? It's been a while since I've cared about these OSX/Windows/GUI paraphernalia. You seem to mean "pulses when it should be xxxing". What is xxx? > and very bad that the stateful system-taskbar progress bars need to > disappear when percent gets to 100 (or times out or whatever) but > don't disappear, sitting at the last remaining reported percentage. Understood. > Anyway, can you try the simpler patch after my sig? It should create > the reporter with 0-100 and also call 'progress-reporter-done' at the > appropriate time (and be a bit less intrusive). > > The only issue with the simpler patch is that if the LSP server sends "end" without first reporting 100, any stateful > progress reporter back ends like system-taskbar's are never cleared. If the server sends 'end' and no percentage my patch (which btw I've just pushed to emacs-31) throws a 100 in there and you should get a call to progress-reporter-done. What else is missing there? > Same if the LSP server dies. Are those conditions we should account > for? The first condition you mention I've tried to address. As to the "server death", I don't think either of our patches handles it. What is an appropriate cleanup function for a progress reporter, just a 'progress-reporter-done' or something else? diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el index 0f0791d37ab..285041653d1 100644 --- a/lisp/progmodes/eglot.el +++ b/lisp/progmodes/eglot.el @@ -1491,6 +1491,11 @@ eglot--on-shutdown (lambda (x) (eq server (get-text-property 0 'eglot--server (car x)))) flymake-list-only-diagnostics)) + ;; Cleanup progress reporters + (maphash (lambda (_ r) + (unless (eq (car r) 'eglot--mode-line-reporter ) + (progress-reporter-done r))) + (eglot--progress-reporters server)) (cond ((eglot--shutdown-requested server) t) ((not (eglot--inhibit-autoreconnect server)) > Did you want to address Microsoft's suggestion to ignore erroneous > progress values? Clearly, they know that LSP servers misbehave and/or > are misimplemented. I'll protect the code if I find actual evidence of misbehavior. Up to now, no such reports existed. In fact this bug was bisected to your changes to the progress reporters ;-) But feel please conjecture a hypothetical scenario where we both can clearly tell there would be (serious?) misbehavior. > For the sake of documentation posterity, I'll include the official LSP > documentation reference here. > > https://github.com/microsoft/language-server-protocol/blob/b7f5132c95261c0898ae5124e7a91707abc48fcd/_specifications/specification-3-16.md?plain=1#L1455 > > The value range is [0, 100]. The value should be steadily > rising. Clients are free to ignore values that are not following this > rule. Why do you keep highlighting that clients are free to ignore this monotony. Is it of particular relevance to this bug or proposed patch? > Finally, can you spare a sentence or two about what the new progress > reporter enables? Alternatively, point me a relevant NEWS entry? > > See > https://github.com/emacs-mirror/emacs/blob/99a9307235ca7e833744adb19e58473b86fc76e8/etc/NEWS#L4089 Thanks. João