GNU bug report logs - #76124
eglot buffer corruption

Previous Next

To reply to this bug, email your comments to 76124 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Johann Höchtl <johann.hoechtl <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: eglot buffer corruption
Date: Fri, 7 Feb 2025 21:14:54 +0100

[Message part 1 (text/plain, inline)]

When I edit a markdown file using markdown-mode AND enable eglot in that
buffer, at least one text operation corrupts the buffer.

When I am on an markdown list item:

- some text a
- some text b []  <-point

and press C-c <up> (which swaps the current list item with the preceding
one), the buffers content gets messed up: Parts of the preceding text are
not properly swapped but "bleeds into" the swapped line.

Possibly eglot and the interaction with "track-changes" is at fault: When I
eglot-shutdown, I never see this corruption.

This is not a visual problem: When I check the eglot logs changes
transfered to the language server or save and revert the buffer I see that
the buffer contains garbled text.

Using emacs as of commit 5e12843fa32150d2f18ce21fc6f3ae58732df6a7

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Johann Höchtl <johann.hoechtl <at> gmail.com>,
 João Távora <joaotavora <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 76124 <at> debbugs.gnu.org
Subject: Re: bug#76124: eglot buffer corruption
Date: Sat, 08 Feb 2025 09:32:18 +0200

> From: Johann Höchtl <johann.hoechtl <at> gmail.com>
> Date: Fri, 7 Feb 2025 21:14:54 +0100
> 
> When I edit a markdown file using markdown-mode AND enable eglot in that buffer, at least one text
> operation corrupts the buffer.
> 
> When I am on an markdown list item:
> 
> - some text a
> - some text b []  <-point
> 
> and press C-c <up> (which swaps the current list item with the preceding one), the buffers content gets
> messed up: Parts of the preceding text are not properly swapped but "bleeds into" the swapped line.
> 
> Possibly eglot and the interaction with "track-changes" is at fault: When I eglot-shutdown, I never see this
> corruption.

I'm guess the information about the LSP server you are using might be
relevant?

> This is not a visual problem: When I check the eglot logs changes transfered to the language server or save
> and revert the buffer I see that the buffer contains garbled text.

Adding João and Stefan to the discussion.


> Using emacs as of commit 5e12843fa32150d2f18ce21fc6f3ae58732df6a7

Is that from the master branch of the Emacs Git repository?  (Your
report elided all version and configuration information, so it's hard
to tell.)

Thanks.

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

From: Johann Höchtl <johann.hoechtl <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: João Távora <joaotavora <at> gmail.com>,
 76124 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#76124: eglot buffer corruption
Date: Sat, 8 Feb 2025 17:47:26 +0100

[Message part 1 (text/plain, inline)]

Am Sa., 8. Feb. 2025 um 08:32 Uhr schrieb Eli Zaretskii <eliz <at> gnu.org>:

> > From: Johann Höchtl <johann.hoechtl <at> gmail.com>
> > Date: Fri, 7 Feb 2025 21:14:54 +0100
> >
> > When I edit a markdown file using markdown-mode AND enable eglot in that
> buffer, at least one text
> > operation corrupts the buffer.
> >
> > When I am on an markdown list item:
> >
> > - some text a
> > - some text b []  <-point
> >
> > and press C-c <up> (which swaps the current list item with the preceding
> one), the buffers content gets
> > messed up: Parts of the preceding text are not properly swapped but
> "bleeds into" the swapped line.
> >
> > Possibly eglot and the interaction with "track-changes" is at fault:
> When I eglot-shutdown, I never see this
> > corruption.
>
> I'm guess the information about the LSP server you are using might be
> relevant?
>
>
I also do not know if this is relevant, but it is
https://github.com/mhersson/mpls


> > This is not a visual problem: When I check the eglot logs changes
> transfered to the language server or save
> > and revert the buffer I see that the buffer contains garbled text.
>
> Adding João and Stefan to the discussion.
>
>
> > Using emacs as of commit 5e12843fa32150d2f18ce21fc6f3ae58732df6a7
>
> Is that from the master branch of the Emacs Git repository?  (Your
> report elided all version and configuration information, so it's hard
> to tell.)
>
>

Does emacs-build-description provide enough details? The output is


In GNU Emacs 31.0.50 (build 1, x86_64-w64-mingw32) of 2025-02-02 built
 on fv-az521-368
Repository revision: 5e12843fa32150d2f18ce21fc6f3ae58732df6a7
Repository branch: HEAD
Windowing system distributor 'Microsoft Corp.', version 10.0.22631
System Description: Microsoft Windows 10 Enterprise (v10.0.2009.22631.4751)

Configured using:
 'configure
 --prefix=/d/a/emacs-build/emacs-build/pkg/5e12843-ucrt-x86_64
 'CFLAGS=-O2 -fno-semantic-interposition -floop-parallelize-all
 -ftree-parallelize-loops=4 -g3 ' --disable-build-details
 --without-dbus --enable-link-time-optimization --enable-build-details
 --with-compress-install --with-small-ja-dic --with-gif --with-gnutls
 --with-harfbuzz --with-jpeg --with-json --with-lcms2 --with-mps
 --with-native-compilation --with-png --with-rsvg --with-tree-sitter
 --with-xml2 --with-xpm --with-zlib --without-cairo --without-tiff'




> Thanks.
>

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Johann Höchtl <johann.hoechtl <at> gmail.com>
Cc: joaotavora <at> gmail.com, 76124 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
Subject: Re: bug#76124: eglot buffer corruption
Date: Sat, 08 Feb 2025 19:04:24 +0200

> From: Johann Höchtl <johann.hoechtl <at> gmail.com>
> Date: Sat, 8 Feb 2025 17:47:26 +0100
> Cc: João Távora <joaotavora <at> gmail.com>, 
> 	Stefan Monnier <monnier <at> iro.umontreal.ca>, 76124 <at> debbugs.gnu.org
> 
>  I'm guess the information about the LSP server you are using might be
>  relevant?
> 
> I also do not know if this is relevant, but it is https://github.com/mhersson/mpls
>  
>  > This is not a visual problem: When I check the eglot logs changes transfered to the language server
>  or save
>  > and revert the buffer I see that the buffer contains garbled text.
> 
>  Adding João and Stefan to the discussion.
> 
>  > Using emacs as of commit 5e12843fa32150d2f18ce21fc6f3ae58732df6a7
> 
>  Is that from the master branch of the Emacs Git repository?  (Your
>  report elided all version and configuration information, so it's hard
>  to tell.)
> 
> Does emacs-build-description provide enough details?

It does, thanks.

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

From: João Távora <joaotavora <at> gmail.com>
To: Johann Höchtl <johann.hoechtl <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 76124 <at> debbugs.gnu.org
Subject: Re: bug#76124: eglot buffer corruption
Date: Sat, 08 Feb 2025 19:55:03 +0000

Johann Höchtl <johann.hoechtl <at> gmail.com> writes:

On Sat, Feb 8, 2025 at 4:47 PM Johann Höchtl <johann.hoechtl <at> gmail.com> wrote:

>> > Possibly eglot and the interaction with "track-changes" is at
>> > fault: When I eglot-shutdown, I never see this corruption.
>> I'm guess the information about the LSP server you are using might be
>> relevant?
> I also do not know if this is relevant, but it is https://github.com/mhersson/mpls

It's normally extremely relevant, as the corruption related to
track-changes and before/after change functions (which you hint at) is
directly dependent on whether the server accepts partial updates or not.

>> > Using emacs as of commit 5e12843fa32150d2f18ce21fc6f3ae58732df6a7
>> Is that from the master branch of the Emacs Git repository?  (Your
>> report elided all version and configuration information, so it's hard
>> to tell.)

(Indeed, I don't see this commit anywhere.  What branch is this?)

Anyway, as to the problem itself, I've reproduced it.

TL/DR: Something in Eglot is making transpose-regions not work correctly
in file-less buffers.

Reproduction: 

It's kind of a fugitive bug, so here's the recipe:

- ensure you have a markdown LSP installed (marksman was easy to do)

- emacs -Q -f package-initialize /tmp/doesntexist.md -f eglot

  'package-initialize' is necessary to somehow bring in markdown.el,
  which isn't a part of Emacs.

- enter this text (disregarding this email's alignment)

  * one
    two
  * three
    four

Place text on first line and type C-c <down>, which invokes
'markdown-move-down'.  The window will scroll, when you scroll up,
you'll see the corruption.  The buffer becomes

  * three
  \@ four
  * one  four

Some notes:

- Doesn't seem to happen in file-supported buffers.

- I used the https://github.com/artempyanykh/marksman server

- track-changes.el is _not_ to blame since the most recent version of
  Eglot I'm using no longer uses that library.

- The 'marksman' server does _not_ use incremental updates, it always
  sends the full buffer text on every didChange update.

- Therefore, this is not the "normal" LSP update-related corruption
  issue.  (for context, in those issues what you see is that the server
  has a skewed image of what exactly is in the buffer, so it misses
  everything).

- I've not been able to reproduce it without Eglot.  So it seems to be
  somewhat related indeed.  It's as if Eglot and the
  'markdown-mode-down' function clashed for some reason.

- Very often, even in file-less buffers, the bug goes away and the C-c
  <up/down> switch works fine, even in Eglot.  I think actually saving
  the buffer into a file does it.

- Part of the garbled text is always invalid character NULL, which Emacs
  renders as ^@, I think.

- The problem happens simplify if you evaluate:

     (transpose-regions 1 12 13 27 nil)

  in that buffer text (the one, two... example.).

- You can also set marks on the regions and call transpose-regions
  interactively. So maybe that particular markdown.el function isn't to
  blame, but buffer settings done by 'markdown-mode' may still be.

- That's all I had time for.

Previous Next

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