bug#62216: Odd file corruption in clojure mode and emacs 30 HEAD

[Jonathon McKitrick]

On Thu, Mar 16, 2023 at 08:50:06AM +0200, Eli Zaretskii wrote:
: > Date: Thu, 16 Mar 2023 00:01:12 +0000
: > From: Jonathon McKitrick <jcm@SDF.ORG>
: > 
: > I realize this is vague, but I'm seeing it consistently:
: > 
: > I build emacs 30 with native compilation on my M1, and I open my work 
clojure project, and I see rainbow parens marking a bunch of unmatched parens.
: > The file will not compile, and the corruption happens simply when I open 
the file.
: > 
: > I do the exact same thing with emacs 29 built the same way, and I have no 
issues.
: > 
: > How can I narrow this down to a useful bug report?
: 
: Thanks for asking, and for the bug report in the first place.
: 
: The way to narrow this down is start with "emacs -Q", add only those
: of your customizations necessary for reproducing the problem, then
: post the results in the form of step by step description of the
: reproduction recipe.  It will help a lot if you also post the file
: which gets corrupted, both before and after the corruption.  If that
: file can be small, that's preferable.
: 
: I'm guessing that you use some third-party packages, at least for
: editing clojure sources.  In that case, include in your description
: the packages one should download to reproduce the issue.
: 
: A description of the recipe should, therefore, look something like the
: following:
: 
:   . download and install the following packages:
:     - foo
:     - bar
:     - ...
:   . start "emacs -Q"
:   . type the following commands:
:     - M-x load-library RET foo RET
:     - M-x load-library RET bar RET
:     - M-x set-variable RET foo-some-var RET t RET
:     -...
:   . visit the attached file foobar.clj
:   . do <something> to trigger the corrption
:   . observe the changes in the file's contents:
:     - <description of the corruptions>
: 
: TIA

I'm frustrated that I cannot reproduce the bug reliably, but it does happen 
constantly under emacs 30. What I have narrowed it down to
is what seems to be a random injection of code from the same file or the kill 
ring. That of course trips up paredit and any compilation.
I check the messages, and cannot tell if there's a random command or key 
binding that triggers a random command responsible for the issue.
I happens with and without native compilation. Since I cannot predict *when* 
it's going to happen, it's difficult to get work done with
packages disabled, not knowing when I'll see the bug.

Has anything like this been reported anywhere else?



Jonathon McKitrick
--
'My other computer is your Linux box.'