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