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

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: rcopley@gmail.com,  70541@debbugs.gnu.org,  joaotavora@gmail.com
> Date: Wed, 24 Apr 2024 10:26:40 -0400
> 
> > Are you sure we want buffer-change hooks to be called here?
> 
> Adding/removing chars from the buffer without running those hooks breaks
> all kinds of assumptions.  It can be acceptable to do it in a very
> temporary way, but Quail doesn't do it temporarily: the whole
> redisplay+timers+filters gets run in the middle of the input of any
> multi-key entry like `^a`, so the "temporary" state is very
> much exposed.

It's exposed to some parts of Emacs, but not to others.

> > Quail intentionally hides some of the modifications it does, because
> > it many times replaces the inserted text with something else, and from
> > the Emacs Lisp program's POV only the final input is the actual
> > "insertion" Emacs should know about.
> 
> I'm not sure why it's important to hide the intermediate steps,

Because Quail emulates keyboard input.  Conceptually, everything that
the user types into a buffer that Quail processes and replaces "did
not happen", only the final insertion of the produced character(s) are
real.

> especially since they're not very well hidden (as evidenced by this bug
> report, and by the fact that font-lock is also triggered every time the
> transient display is modified).

Actually, it's hidden quite well, it's just that Eglot gets confused
because it looks at stuff it isn't supposed to see ;-)

> Note that when users use Abbrev instead to turn \lambda into λ, the
> intermediate steps are not hidden, and that's not been a problem.

Abbrev cannot guide the user regarding the next steps when an initial
string typed by user has several possible candidates for further
input.  So Abbrev basically solves a simpler problem.

> > So I'm not sure we should install this, as it could break something
> > elsewhere.  Aren't there any alternatives to this?
> 
> We could change Quail so it refrains from temporarily modifying the
> buffer, using an `after/before-string` on an overlay instead.
> It'd be a fairly significant change in `quail.el` and would probably
> come with its own share of problems.

I'm not at all sure the solution should be in Quail.

> > More generally,
> > why should Eglot care about these low-level details of Quail?
> 
> Because Eglot syncs up with the LSP server via a timer, so it sees the
> buffer with an extra "^" char in it.

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