From: "João Távora" <joaotavora@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Richard Copley <rcopley@gmail.com>,
70541-done@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
Subject: bug#70541: track-changes-mode logs warnings (with input method, in Eglot buffer)
Date: Sun, 5 May 2024 17:10:31 +0100 [thread overview]
Message-ID: <CALDnm52TWq4Bo+JUeC6tmWwG=uZxnf54RaidfcVZuFDxV7oVcA@mail.gmail.com> (raw)
In-Reply-To: <jwv8r0o5n4l.fsf-monnier+emacs@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 3061 bytes --]
On Sun, May 5, 2024 at 3:58 PM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:
> > Is this really the final word on this whole topic? The current
> > solution involves a one shot addition to `post-command-hook` in Eglot
> > and is really ugly. Can you really really no better solution so that
> > Eglot is only compelled to send changes to the server once
> > track-changes.el announces it safe to do so (and gives the change to
> > send while it's at it?
>
> Until we've gotten rid of all the code chunks that incorrectly use
> `inhibit-modification-hooks` (which will take a lot of time since not
> only we have to find them but we have to figure out why they used
> `inhibit-modification-hooks` and then argue hard to get the change to be
> accepted), I don't see a significantly simpler solution, no. 🙁
>
> I mean, a simpler solution is to live with the performance bug, of course.
>
I don't know that this is a "performance bug". I mean, misleading the
server,
crashing it is only such a thing if one squints very hard.
So while may be "significantly simpler" solution isn't in the cards,
I still think some simplification can happen (I don't understand
why post-command-hook needs to be used for example).
Anyway, I would need to see the quil failure scenario encoded as a
test in eglot-tests.el so I can have a clear shot at it. Should be
possible, no?
>
> > Also, tangentially , can we get rid of the fboundp's and make the next
> GNU
> > ELPA version run the same code as Emacs master's by depending on
> > track-changes.el GNU core?
>
> Yes, coming right up.
>
Thanks. That's great. It would also help to document your new
eglot--track-changes-fetch. I'm afraid I've lost track of how the
code is supposed to work after track-changes.el
* why is :emacs-messup still a thing? By the way did :emacs-messup
solve this very problem too via a full resync?
* what exactly does the local eglot--track-changes do and why would
it be re-registered in the same buffer (why isn't the typical add-hook
enough).
* There seems to be a track-changes.el signalling function and the
longstanding LSP signalling function that informs the server of
things. Why can't it be the same function, i.e. why can't Eglot
tell track-changes.el to call Eglot's function when track-changes.el
knows it's a safe time to call such a function? The flow of
information via the eglot--recent-changes variable is complicated
and would seem not worth bringing in track-changes.el at all.
Is it only to accommodate Eglot versions when track-changes.el
isn't available or is there some deeper reason?
> > Also also, can you fix indentation in the function that you recently
> > touched in Eglot? (same goes for Philip, but I'll contact him
> > separately).
>
> Hmm... hadn't notice anything wrong. Will take a closer look, thanks
> for the heads up.
>
Not serious, it's just I was misled by the misindentation when reading
one of the new if's, thinking it only had a then branch.
João
[-- Attachment #2: Type: text/html, Size: 4204 bytes --]
next prev parent reply other threads:[~2024-05-05 16:10 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-23 20:44 bug#70541: track-changes-mode logs warnings (with input method, in Eglot buffer) Richard Copley
2024-04-24 3:14 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-24 7:12 ` Eli Zaretskii
2024-04-24 14:26 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-24 15:42 ` Eli Zaretskii
2024-04-24 19:02 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-24 19:24 ` Eli Zaretskii
2024-04-24 20:53 ` João Távora
2024-04-28 18:21 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-29 6:09 ` Eli Zaretskii
2024-04-29 8:28 ` João Távora
2024-04-29 8:36 ` Ihor Radchenko
2024-04-29 8:45 ` Eli Zaretskii
2024-04-29 19:45 ` Ihor Radchenko
2024-04-29 20:27 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-03 17:27 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-03 20:56 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-04 18:08 ` Richard Copley
2024-05-04 19:59 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-04 21:16 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-05 0:52 ` Richard Copley
2024-05-05 13:40 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-05 13:55 ` João Távora
2024-05-05 14:57 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-05 16:10 ` João Távora [this message]
2024-05-05 17:48 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-29 8:57 ` João Távora
2024-04-29 20:50 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALDnm52TWq4Bo+JUeC6tmWwG=uZxnf54RaidfcVZuFDxV7oVcA@mail.gmail.com' \
--to=joaotavora@gmail.com \
--cc=70541-done@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=rcopley@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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).