GNU bug report logs - #59149
Feature Request: Report progress of long requests in Eglot

Previous Next

Full log

View this message in rfc822 format

From: Danny Freeman <danny <at> dfreeman.email>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 59149 <at> debbugs.gnu.org, stephen_leake <at> stephe-leake.org, joaotavora <at> gmail.com
Subject: bug#59149: [SPAM UNSURE] Re: bug#59149: Feature Request: Report progress of long requests in Eglot
Date: Fri, 25 Nov 2022 11:44:03 -0500

I meant to reply to this and Eli's feedback in one email.

> OK.  Let's have Danny's opinion on it, especially on the name
> 'eglot-report-progress'.  In the simplest case, this variable is a
> boolean, but I am curious if other types of progress reporting can be
> envisioned.  If they are, they should be controlled by the least amount
> of user variables possible.

I think a boolean will be sufficient, but I'm not sure how this will
evolve in the future.

From the perspective of the LSP specification, there is only ONE type of
progress message defined in the spec, and that is "Work Done Progress",
which is what my patch supports. The spec does leave room for other
usage of the progress message, including for "streaming of results",
which I have never seen used in practice.

From the spec:
https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#progress
"""
The base protocol offers also support to report progress in a generic
fashion. This mechanism can be used to report any kind of progress
including work done progress (usually used to report progress in the
user interface using a progress bar) and partial result progress to
support streaming of results.
"""

What kind of variable might allow Eglot to naturally evolve with this
part of the spec? Maybe a list similar to `eglot-stay-out-of`?

It may also help to keep in mind that some of these "Work Done Progress"
requests can be canceled by the user. Later I think it would be nice to
expose a command that would send the server a cancel request while one
of these "progress" things is in flight. I'm not sure how that might
affect a custom var here, but thought I would mention it.

-- 
Danny Freeman

Previous Next

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