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

Previous Next

Full log

Message #20 received at 70541 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rcopley <at> gmail.com, 70541 <at> debbugs.gnu.org, joaotavora <at> gmail.com
Subject: Re: bug#70541: track-changes-mode logs warnings (with input method,
 in Eglot buffer)
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?
Tree-sitter is told about it, font-lock is told about it, why not others
via the usual mechanism?  What's different about Eglot?

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

When combined with appropriate completion tables and UIs, abbrev also
guide the user, so it's not that different.
Also, I fail to see how that's relevant.

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

> 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.  And how are they going to deal with it?

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
`^`).

This is pretty ugly in my book, sounds like workarounds on top
of workarounds.  Can we try the patch I suggested first?
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.

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


        Stefan

Previous Next

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