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

[Stefan Monnier]

>> 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.

But what does it mean concretely?  In which sense is it supposed not
to exist?
And more to the point, what makes it important to hide those changes?

>> > 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?

No, the problem was there before just as well.  The difference is that
`track-changes.el` is more careful both to detect and to report
such problems.

> It worked fine before that, with the same Quail, right?

Yes and no: in some cases the old code failed to detect the problem and
that could result in broken behavior.  When the old and new code detect
the problem, they both "work fine" in the sense that the behavior is
correct but at an extra cost because after detecting the inconsistency
Eglot does a full resync with the server.

> Or am I missing something?

It also works correctly with the new code.  The difference is that we
report it (notice the `Subject:` says "warning").
[ Note also that `track-changes.el` does not warn about it when running
  in a released version of Emacs (see `track-changes-record-errors`),
  because I assume it's less useful.  ]

>> And how are they going to deal with it?
> By ignoring the changes performed while that flag is set.

Define "ignore".
The change are there.  `point`, `point-max`, `current-column`,
etc... are affected.

>> 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?

Which other times are you referring to?


        Stefan