bug#59149: [SPAM UNSURE] Re: bug#59149: Feature Request: Report progress of long requests in Eglot

[João Távora]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> João Távora <joaotavora@gmail.com> writes:
>
>> On Wed, Nov 23, 2022 at 7:45 PM Danny Freeman <danny@dfreeman.email> wrote:
>>>
>>>
>>> Stephen Leake <stephen_leake@stephe-leake.org> writes:
>>>
>>> I am copying him on this email, as I realize he wasn't on this branch of
>>> the email chain. João, please see the previous emails in the thread for
>>> more context! Here is a link for convenience:
>>> https://lists.gnu.org/archive/html/bug-gnu-emacs/2022-11/msg01619.html
>>
>> Yep this is all news to me, but no problem, I just read through the chain.
>>
>> If, like Stephen says, $progress is part of the base protocol, then there's
>> no capability associated indeed, but I think we should just make up one
>> like `:$progress`, and use change eglot--server-capable-p to be able
>> to respond unequivocally 't' to those special built in capabilities, but
>> only after checking if they're not in the eglot-ignored-server-capabilities
>> list.
>
> One way to do that is to simply add (:$progresss t) in eglot--connect
> where eglot--capabilities is set.

Yes that would probably do it as an implementation trick.

> But apply-text-edits creates a progress reporter that is not driven by
> messages from the lsp server; it's just processing a local list of
> edits. And I would like to be able to turn that off, but keep (at least
> some of) the lsp progress messages.
>
> LSP capabilities handle this by adding items in categories, so we could
> add (:$progress (:apply-edit t)) to eglot--capabilities, and then I
> could add :apply-edit to eglot-ignored-server-capabilities. We'd have to
> do the same for any other progress message somebody wants to turn off.
>
> Except that would also turn off apply-edit itself, not just the progress
> messages for it; it seems we need to allow
> eglot-ignored-server-capabilities to contain (:$progress :apply-edit).
> Or use :apply-edit-progress instead.

At this point, I'm not sure the eglot-ignored-server-capabilities is the
right tool for the job.  In fact, even my original suggestion is a bit
sketchy, because it is creating these pseudo-capabilities that don't
really exist.  Abusing it even further is probably not good.

So, here three possible things we can do:

1. Get rid of the :apply-edit progress reporter entirely. To be honest,
   I don't think it's doing much.  We could just as well have a call to
   message there, or nothing at all.

2. Do my original "sketchy" suggestion, where :$progress is considered a
   built-in ignorable capability (and checked with eglot--server-capable
   in the new code that Danny is proposing).  Stephen's eglot-connect
   trick is an acceptable technique.

3. Add a boolean user varible eglot-report-progress.  I don't like to
   add user variables unless they represent things directly related to
   the fundamental LSP logic, and not its customization or evolution.
   Since this seems to be of those fundamental things, I think it's
   acceptable.

The alternatives are:

a: 1+2
b: 1+3
c: 2
d: 3

Stephen, you request to shoosh that particular apply-edits progress
reporter is another separate request, we shouldn't let it block Danny's
effort to support $progress messages.  So I think we should do either
'c' or 'd' for now, and we can always address your request later.

João