bug#81514: 32.0.50; Eglot messages progress reporter shows errors

Stéphane Marks <[email protected]> Thu, 30 Jul 2026 16:55:24 +0200
Newsgroups gmane.emacs.bugs
Message-ID <CAN+1Hbrd66DFPQs1-u2d+7ZRjEov7cSG6HDM4DqP=ORsa4WarQ@mail.gmail.com>
On Wed, Jul 29, 2026 at 8:46 PM João Távora <[email protected]> wrote:

> Stéphane Marks <[email protected]> writes:
>
> > On Wed, Jul 29, 2026 at 7:25 PM João Távora <[email protected]>
> wrote:
> >
> >  Haven't read it, but see lots of + and only one - which makes me frown.
> What was so wrong in Eglot's use of this
> >  facility, which worked fine afaict until your changes?
> >
> > Two issues with it.  First is that the LSP progress messages are
> percentages growing from 0-100 and the pulsing reporter
> > was incorrect for that use.
>
> OK, this is the part you fix by passing 0 and 100 to
> make-progress-reporter, right?
>

Right.

> It shows visibly when one uses the Emacs 31 system-taskbar progress
> reporters that display
> > graphical bars representing % completion.
>
> I don't understand this.  What shows visibly?


macOS, MS-Windows, and GNU/Linux progress bars on the Emacs application
icon.


> Is it good or bad that it
> shows visibly?


Good.


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


> There are four combinations in total
>
>    Your Eglot patch   Your PR patch
> 1. no                 no
> 2. no                 yes
> 3. yes                no
> 4. yes                yes
>
> I presume 1 was fine (it worked like that for a number of years).  I
> also presume that 3 and 4 fine.  I suppose 2 is the error in this bug.
>
> > Second is that those stateful progress bars need to be cleared when
> > the progress reporter is considered "done."  So we changed from a
> > pulsing reporter to a "numeric" reporter and correctly called
> > progress-reporter-done at the end.
>
> You're describing your Eglot patch, which is not pushed, right?
>

Right.

> We amended the Tramp progress reporter similarly recently.
>
> Does this mean you already pushed a similar fix to Tramp?
>

Yes.  See
https://github.com/emacs-mirror/emacs/commit/0448b4e09af24606fd807b1d8bbf852459e7d2e1


> 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.  Same if the LSP server dies.  Are
those conditions we should account for?

Did you want to address Microsoft's suggestion to ignore erroneous progress
values?  Clearly, they know that LSP servers misbehave and/or are
misimplemented.  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.

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


> It
> seems that this new framework supports other "outlets" other than
> *Messages* and the echo area.  Am I correct?


Yes.  We expanded progress-reporter to include a list of progress reporter
back ends to update per "tick."


> If so, the docstring of
> eglot-report-progress can be amended or even its default value changed
> if the new functionality is more appealing.
>

The symbol 'messages now also implies other configured progress reporter
back ends beyond the echo area.  Perhaps the docstring can be amplified to
say that.  I'm not sure the current docstring is correct as it says
*Messages* but does not mention the echo area.

João
>
> diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el
> index f701a38ab8b..0f0791d37ab 100644
> --- a/lisp/progmodes/eglot.el
> +++ b/lisp/progmodes/eglot.el
> @@ -2872,7 +2872,8 @@ eglot-handle-notification
>                  (if (eq eglot-report-progress 'messages)
>                      (make-progress-reporter
>                       (format "[eglot] %s %s: %s"
> -                             (eglot-project-nickname server) token title))
> +                             (eglot-project-nickname server) token title)
> +                     0 100)
>                    (list 'eglot--mode-line-reporter token title)))
>                (upd (pcnt msg &optional
>                           (pr (gethash token (eglot--progress-reporters
> server))))
> @@ -2880,7 +2881,10 @@ eglot-handle-notification
>                    ((eq (car pr) 'eglot--mode-line-reporter)
>                     (setcdr (cddr pr) (list msg pcnt))
>                     (force-mode-line-update t))
> -                  (pr (eglot--reporter-update pr pcnt msg)))))
> +                  (pr
> +                   (if (eql pcnt 100)
> +                       (progress-reporter-done pr)
> +                     (eglot--reporter-update pr pcnt msg))))))
>        (eglot--dbind ((WorkDoneProgress) kind title percentage message)
> value
>          (pcase kind
>            ("begin"
>