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

Previous Next

Package: emacs;

Reported by: Danny Freeman <danny <at> dfreeman.email>

Date: Wed, 9 Nov 2022 14:24:01 UTC

Severity: wishlist

Done: João Távora <joaotavora <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #68 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stephen Leake <stephen_leake <at> stephe-leake.org>
To: João Távora <joaotavora <at> gmail.com>
Cc: 59149 <at> debbugs.gnu.org, bug-gnu-emacs <at> gnu.org,
 Danny Freeman <danny <at> dfreeman.email>
Subject: Re: [SPAM UNSURE] Re: bug#59149: Feature Request: Report progress
 of long requests in Eglot
Date: Thu, 24 Nov 2022 13:25:53 -0800
João Távora <joaotavora <at> gmail.com> writes:

> Stephen Leake <stephen_leake <at> stephe-leake.org> writes:
>
>> João Távora <joaotavora <at> gmail.com> writes:
>>
> 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.

It might be worth keeping a "debug message" there, gated by a new
variable eglot--debug (boolean or integer). So we can turn on messages
when we need to debug something.

Or just keep it commented out; it's easy enough to run eval-defun after
uncommenting.

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

Ok. Since that rules out b, I vote for d.
 

-- 
-- Stephe




This bug report was last modified 2 years and 161 days ago.

Previous Next


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