From: Stephen Leake <stephen_leake@stephe-leake.org>
To: "João Távora" <joaotavora@gmail.com>
Cc: 59149@debbugs.gnu.org, danny@dfreeman.email
Subject: bug#59149: [SPAM UNSURE] Re: bug#59149: Feature Request: Report progress of long requests in Eglot
Date: Thu, 24 Nov 2022 13:25:53 -0800 [thread overview]
Message-ID: <8635a8jb8e.fsf@stephe-leake.org> (raw)
In-Reply-To: <87o7swv3nx.fsf@gmail.com> ("João Távora"'s message of "Thu, 24 Nov 2022 14:16:18 +0000")
João Távora <joaotavora@gmail.com> writes:
> Stephen Leake <stephen_leake@stephe-leake.org> writes:
>
>> João Távora <joaotavora@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
next prev parent reply other threads:[~2022-11-24 21:25 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-09 14:13 bug#59149: Feature Request: Report progress of long requests in Eglot Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-10 15:50 ` João Távora
2022-11-11 13:07 ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-19 9:42 ` Stephen Leake
2022-11-19 18:03 ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-21 18:04 ` Stephen Leake
2022-11-23 14:12 ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-23 18:01 ` Stephen Leake
2022-11-23 19:36 ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-23 19:56 ` João Távora
2022-11-24 11:06 ` bug#59149: [SPAM UNSURE] " Stephen Leake
2022-11-24 14:16 ` João Távora
2022-11-24 21:25 ` Stephen Leake [this message]
2022-11-25 16:11 ` João Távora
2022-11-25 16:15 ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-25 16:31 ` Eli Zaretskii
2022-11-25 16:41 ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-25 16:44 ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-26 1:03 ` João Távora
2022-11-26 18:37 ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-26 19:46 ` Stefan Kangas
2022-12-01 13:29 ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-03 13:23 ` João Távora
2022-12-09 13:06 ` João Távora
2022-12-09 13:38 ` Danny Freeman via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-22 18:45 ` Stephen Leake
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8635a8jb8e.fsf@stephe-leake.org \
--to=stephen_leake@stephe-leake.org \
--cc=59149@debbugs.gnu.org \
--cc=danny@dfreeman.email \
--cc=joaotavora@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.