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

Previous Next

Package: emacs;

Reported by: Richard Copley <rcopley <at> gmail.com>

Date: Tue, 23 Apr 2024 20:46:03 UTC

Severity: normal

Done: Stefan Monnier <monnier <at> iro.umontreal.ca>

Bug is archived. No further changes may be made.

Full log


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

From: Richard Copley <rcopley <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 70541 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 João Távora <joaotavora <at> gmail.com>
Subject: Re: bug#70541: track-changes-mode logs warnings (with input method,
 in Eglot buffer)
Date: Sat, 4 May 2024 19:08:14 +0100
On Fri, 3 May 2024 at 18:27, Stefan Monnier <monnier <at> iro.umontreal.ca> 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 <monnier <at> iro.umontreal.ca> 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.




This bug report was last modified 1 year and 71 days ago.

Previous Next


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