GNU bug report logs -
#44303
28.0.50; json-pretty-print-buffer creates spurious lock file
Previous Next
Reported by: Simen Heggestøyl <simenheg <at> runbox.com>
Date: Thu, 29 Oct 2020 10:01:02 UTC
Severity: normal
Found in version 28.0.50
Done: Simen Heggestøyl <simenheg <at> runbox.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 44303 in the body.
You can then email your comments to 44303 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44303; Package
emacs.
(Thu, 29 Oct 2020 10:01:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Simen Heggestøyl <simenheg <at> runbox.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 29 Oct 2020 10:01:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Given a file named 'test.json' with the following content: {}
From 'emacs -Q', visit the file and call 'json-pretty-print-buffer'.
The buffer stays unchanged as expected since the pretty printed content
is identical to the original. The buffer is not marked as modified (also
expected), but a spurious lock file '.#test.json' has been created.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44303; Package
emacs.
(Fri, 30 Oct 2020 13:30:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 44303 <at> debbugs.gnu.org (full text, mbox):
Simen Heggestøyl <simenheg <at> runbox.com> writes:
> Given a file named 'test.json' with the following content: {}
>
>>From 'emacs -Q', visit the file and call 'json-pretty-print-buffer'.
>
> The buffer stays unchanged as expected since the pretty printed content
> is identical to the original. The buffer is not marked as modified (also
> expected), but a spurious lock file '.#test.json' has been created.
Yup. It's this code in Freplace_buffer_contents:
if (!inhibit_modification_hooks)
{
prepare_to_modify_buffer (BEGV, ZV, NULL);
specbind (Qinhibit_modification_hooks, Qt);
modification_hooks_inhibited = true;
}
prepare_to_modify_buffer creates the backup file.
But is that even needed here? Don't the later
Finsert_buffer_substring/del_range_both functions do the necessary
bookkeeping?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44303; Package
emacs.
(Fri, 30 Oct 2020 13:32:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 44303 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> But is that even needed here? Don't the later
> Finsert_buffer_substring/del_range_both functions do the necessary
> bookkeeping?
Aha, it was previously:
- /* If k >= l, it means nothing needs to be deleted. */
- if (k < l)
- prepare_to_modify_buffer (from, to, NULL);
+ prepare_to_modify_buffer (from, to, NULL);
So it needs to be done in the del_range_both case? Which makes some
sense. Perhaps it can just be moved down into the loop (and done once
if it hasn't been done before)?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44303; Package
emacs.
(Fri, 30 Oct 2020 13:36:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 44303 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Fri, 30 Oct 2020 14:28:59 +0100
> Cc: 44303 <at> debbugs.gnu.org
>
> > The buffer stays unchanged as expected since the pretty printed content
> > is identical to the original. The buffer is not marked as modified (also
> > expected), but a spurious lock file '.#test.json' has been created.
>
> Yup. It's this code in Freplace_buffer_contents:
>
> if (!inhibit_modification_hooks)
> {
> prepare_to_modify_buffer (BEGV, ZV, NULL);
> specbind (Qinhibit_modification_hooks, Qt);
> modification_hooks_inhibited = true;
> }
>
> prepare_to_modify_buffer creates the backup file.
But we then have this:
if (modification_hooks_inhibited)
{
signal_after_change (BEGV, size_a, ZV - BEGV);
update_compositions (BEGV, ZV, CHECK_INSIDE);
}
Does this not work, or fail to unlock the file?
> But is that even needed here? Don't the later
> Finsert_buffer_substring/del_range_both functions do the necessary
> bookkeeping?
We disable that by binding inhibit_modification_hooks, and we do that
for speed, see the comment before that code.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44303; Package
emacs.
(Sun, 01 Nov 2020 12:07:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 44303 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> But we then have this:
>
> if (modification_hooks_inhibited)
> {
> signal_after_change (BEGV, size_a, ZV - BEGV);
> update_compositions (BEGV, ZV, CHECK_INSIDE);
> }
>
> Does this not work, or fail to unlock the file?
This does not unlock the file in the test case.
>> But is that even needed here? Don't the later
>> Finsert_buffer_substring/del_range_both functions do the necessary
>> bookkeeping?
>
> We disable that by binding inhibit_modification_hooks, and we do that
> for speed, see the comment before that code.
Ah, I see. The missing piece of the puzzle was this bit, which I wasn't
aware of:
----
Setting this variable non-nil also inhibits file locks and checks
whether files are locked by another Emacs session, as well as
handling of the active region per ‘select-active-regions’.
----
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44303; Package
emacs.
(Sat, 07 Nov 2020 10:33:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 44303 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: simenheg <at> runbox.com, 44303 <at> debbugs.gnu.org
> Date: Sun, 01 Nov 2020 13:06:00 +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > But we then have this:
> >
> > if (modification_hooks_inhibited)
> > {
> > signal_after_change (BEGV, size_a, ZV - BEGV);
> > update_compositions (BEGV, ZV, CHECK_INSIDE);
> > }
> >
> > Does this not work, or fail to unlock the file?
>
> This does not unlock the file in the test case.
Should be fixed now on master.
I wonder whether we should actually cherry-pick this to the release
branch. The original recipe doesn't trigger the problem there, but
that's because json-pretty-print-buffer does modify the buffer on
emacs-27. If it didn't, we'd probably have the same problem in Emacs
27.
Thoughts?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44303; Package
emacs.
(Mon, 09 Nov 2020 08:25:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 44303 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Should be fixed now on master.
Hm, did you push it? I'm still experiencing the bug on master (as of
795b7da16b).
> I wonder whether we should actually cherry-pick this to the release
> branch. The original recipe doesn't trigger the problem there, but
> that's because json-pretty-print-buffer does modify the buffer on
> emacs-27. If it didn't, we'd probably have the same problem in Emacs
> 27.
Right. You can see the bug in Emacs 27 too by using a test file like
this instead:
{
}
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44303; Package
emacs.
(Mon, 09 Nov 2020 14:04:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 44303 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> I wonder whether we should actually cherry-pick this to the release
> branch.
(You've possibly forgotten to push the change?)
It's a somewhat obscure bug that'll basically only manifest in
situations like this, so I'm not sure that it's worth it. But I haven't
seen the patch -- if it's totally trivial, then sure.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44303; Package
emacs.
(Mon, 09 Nov 2020 15:59:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 44303 <at> debbugs.gnu.org (full text, mbox):
> From: Simen Heggestøyl <simenheg <at> runbox.com>
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 44303 <at> debbugs.gnu.org
> Date: Mon, 09 Nov 2020 09:24:03 +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Should be fixed now on master.
>
> Hm, did you push it? I'm still experiencing the bug on master (as of
> 795b7da16b).
Sorry, I forgot to push. Done now, please check.
> > I wonder whether we should actually cherry-pick this to the release
> > branch. The original recipe doesn't trigger the problem there, but
> > that's because json-pretty-print-buffer does modify the buffer on
> > emacs-27. If it didn't, we'd probably have the same problem in Emacs
> > 27.
>
> Right. You can see the bug in Emacs 27 too by using a test file like
> this instead:
>
> {
> }
OK, will cherry-pick.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44303; Package
emacs.
(Mon, 09 Nov 2020 16:09:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 44303 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: simenheg <at> runbox.com, 44303 <at> debbugs.gnu.org
> Date: Mon, 09 Nov 2020 15:03:07 +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > I wonder whether we should actually cherry-pick this to the release
> > branch.
>
> (You've possibly forgotten to push the change?)
>
> It's a somewhat obscure bug that'll basically only manifest in
> situations like this, so I'm not sure that it's worth it. But I haven't
> seen the patch -- if it's totally trivial, then sure.
I think it's totally trivial, yes. But I'm obviously biased.
Reply sent
to
Simen Heggestøyl <simenheg <at> runbox.com>:
You have taken responsibility.
(Mon, 09 Nov 2020 16:38:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Simen Heggestøyl <simenheg <at> runbox.com>:
bug acknowledged by developer.
(Mon, 09 Nov 2020 16:38:01 GMT)
Full text and
rfc822 format available.
Message #37 received at 44303-done <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Simen Heggestøyl <simenheg <at> runbox.com>
>> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 44303 <at> debbugs.gnu.org
>> Date: Mon, 09 Nov 2020 09:24:03 +0100
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> > Should be fixed now on master.
>>
>> Hm, did you push it? I'm still experiencing the bug on master (as of
>> 795b7da16b).
>
> Sorry, I forgot to push. Done now, please check.
Works for me. Thanks!
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#44303; Package
emacs.
(Sat, 14 Nov 2020 13:27:02 GMT)
Full text and
rfc822 format available.
Message #40 received at 44303-done <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 09 Nov 2020 17:58:12 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: larsi <at> gnus.org, 44303 <at> debbugs.gnu.org
>
> > > I wonder whether we should actually cherry-pick this to the release
> > > branch. The original recipe doesn't trigger the problem there, but
> > > that's because json-pretty-print-buffer does modify the buffer on
> > > emacs-27. If it didn't, we'd probably have the same problem in Emacs
> > > 27.
> >
> > Right. You can see the bug in Emacs 27 too by using a test file like
> > this instead:
> >
> > {
> > }
>
> OK, will cherry-pick.
Now done.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sun, 13 Dec 2020 12:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 188 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.