GNU bug report logs - #70541
track-changes-mode logs warnings (with input method, in Eglot buffer)

Previous Next

Full log

View this message in rfc822 format

From: João Távora <joaotavora <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Richard Copley <rcopley <at> gmail.com>, 70541-done <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> 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

[Message part 1 (text/plain, inline)]

On Sun, May 5, 2024 at 3:58 PM Stefan Monnier <monnier <at> 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

[Message part 2 (text/html, inline)]

Previous Next

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