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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: rcopley@gmail.com,  70541@debbugs.gnu.org,  joaotavora@gmail.com
> Date: Wed, 24 Apr 2024 15:02:47 -0400
> 
> > Actually, it's hidden quite well, it's just that Eglot gets confused
> > because it looks at stuff it isn't supposed to see ;-)
> 
> Who's supposed to see it and who isn't?

Those who need to know are supposed to see, the rest aren't ;-)

Seriously, though:

> The buffer state is modified by Quail.  It's somewhat temporary but
> there's still a lot that can happen during that temporary state.

It isn't just temporary: it's a change that "isn't supposed to exist".
It's just a side effect of how Quail is implemented.

> > So maybe Eglot should learn that when it sees this and a Quail input
> > is in progress, it should pretend it didn't see anything?
> 
> That seems very yucky.  Suddenly packages like Eglot, lsp-mode, crdt,
> TeXpresso, CriticalMarkup, ... need to learn about that special
> interaction with Quail.

It isn't suddenly, it's because you switched Eglot to the new
track-changes method, right?  It worked fine before that, with the
same Quail, right?  Or am I missing something?

And why "yucky"?  This is the same Quail in all those cases, and the
same track-changes machinery.  So if Quail gets in the way of
track-changes, how about if Quail sets some flag which tells the
application level that changes in progress are to be ignored?  If we
can handle that as part of track-changes, fine; otherwise, Eglot and
the rest that use track-changes will have to ignore that on the
application level.  Doesn't sound yucky to me.

> And how are they going to deal with it?

By ignoring the changes performed while that flag is set.

> The only sane way I can see to deal with it would be for Quail to
> provide a way to temporarily return to the "real" state (e.g. deleting
> the `^`) and then to get back to the temporary state (i.e. re-insert the
> `^`).

Why is it not enough to ignore the changes?

> This is pretty ugly in my book, sounds like workarounds on top
> of workarounds.  Can we try the patch I suggested first?

We could try, but how many times do we need to make changes like that
in Quail that bite us elsewhere before we learn the simple truth that
we shouldn't try that anymore?

> It makes more code normal instead of adding more special code to deal
> with special code, so if that works it's a much nicer option.

Once again: Quail uses with-silent-modifications for a reason.  You
are basically suggesting to ignore that reason, and hwy? because it
makes the solution much easier?  A simpler solution is only preferable
when we know for sure it is correct, and here we are just guessing,
since we don't really have a clear idea what will that cause in other
cases.

> > IOW, why not solve this in Eglot instead?  It's Eglot that makes
> > incorrect assumptions about what happens, so let's teach Eglot how to
> > do better.
> 
> I don't think these are incorrect assumptions because there's not much
> else it could do.  If packages like Eglot can't do their work correctly
> without knowing about Quail, I think it means we have a poor API.

I'm suggesting a way for Quail to tell those applications that it is
in the process of making changes that should be ignored.  If such a
mechanism is possible, I think those applications could DTRT without
much effort.  Or am I missing something?