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

From: Richard Copley <[email-masked]>
Date: Sat, 4 May 2024 19:08:14 +0100

On Fri, 3 May 2024 at 18:27, Stefan Monnier <[email-masked]> wrote:
> I just pushed a patch to `master` which does that.
> Richard, can you confirm it fixes the problem on your end?

On Fri, 3 May 2024 at 21:56, Stefan Monnier <[email-masked]> wrote:
> It seems to work OK for me now, but I'd like to hear other people's
> experience with it.

Thanks Stefan.

One can trigger the track-changes signal in such a way as to defeat
the new check, as follows.

* Ensure clangd is on the path.
* Visit a C++ file with these contents:

void f () {
  int x = 0;
  int a = b;
}

* Start Eglot. (The "b" is highlighted to indicate an error.)
* Enable the TeX input method.
* Put point after the zero.
* (Enter the bad state.) Quickly, type [<backspace> ^]. Pause.
* Type [<backspace> y]. (No error highlight on "y".)
* Move point to before the "x". (No "variable x" echo from Eldoc.)
* Move point back to after the "y".
* Type [<backspace> z] again. (Still no error highlight on "z".)
* Type [SPC]. (Highlight on "b" is now rendered incorrectly.)
* (Exit the bad state.) Type [C-n SPC <backspace>].

Expected behaviour: After typing "y", Eglot sends "textDocument/didChange",
clangd sends "textDocument/publishDiagnostics" and Flymake highlights the
"y" to indicate an error.

Actual behaviour: After typing "y", no "textDocument/didChange" is sent
and the "y" is not highlighted. Further edits at the same buffer position
(even after moving point away and back again) do not recover the expected
highlighting, and point motion doesn't trigger LSP hover messages, until
one returns to a normal state by making changes elsewhere in the buffer.

If this happens when an edit was made with the intention of getting
feedback from the language server, it will be inconvenient.