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: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: rcopley <at> gmail.com, 70541 <at> debbugs.gnu.org, joaotavora <at> gmail.com
Subject: bug#70541: track-changes-mode logs warnings (with input method, in Eglot buffer)
Date: Mon, 29 Apr 2024 09:09:23 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: rcopley <at> gmail.com,  70541 <at> debbugs.gnu.org,  joaotavora <at> gmail.com
> Date: Sun, 28 Apr 2024 14:21:19 -0400
> 
> >> 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?

The actual change is the character(s) inserted when the Quail input
function completes its job.  Everything else is ephemeral, and Quail
deletes it as part of its job.  So those insertions followed by
deletions are not meant to change the buffer, and should therefore be
ignored.

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

So this is actually a non-issue?

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

Do nothing and wait for the flag to become reset again.

> The change are there.  `point`, `point-max`, `current-column`,
> etc... are affected.

Why does Eglot need to react to those changes immediately when they
happen?

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

For example, we made several changes in Quail and elsewhere to fix the
recording of characters and the related keyboard-macro issues.  It
took quite some effort to get that right and fix all the regressions
the initial too-naïve attempts caused elsewhere.

So I'd very much prefer that Quail signaled to applications that it's
in the middle of handling some complex input, and that applications
which track changes ignored the changes made during this period.

We might already have variables in Quail which could be used as such
flags: quail-translating, quail-converting, quail-current-str, and
quail-guidance-str, to name a few candidates.  Could any of them be
used for this purpose?

Previous Next

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