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

[Stephen Leake]

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.


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.

-- 
-- Stephe