bug#44303: 28.0.50; json-pretty-print-buffer creates spurious lock file

bug#44303: 28.0.50; json-pretty-print-buffer creates spurious lock file

[Simen Heggestøyl]

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.

bug#44303: 28.0.50; json-pretty-print-buffer creates spurious lock file

[Lars Ingebrigtsen]

Simen Heggestøyl <simenheg@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

bug#44303: 28.0.50; json-pretty-print-buffer creates spurious lock file

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@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

bug#44303: 28.0.50; json-pretty-print-buffer creates spurious lock file

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 30 Oct 2020 14:28:59 +0100
> Cc: 44303@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.

bug#44303: 28.0.50; json-pretty-print-buffer creates spurious lock file

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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

bug#44303: 28.0.50; json-pretty-print-buffer creates spurious lock file

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: simenheg@runbox.com,  44303@debbugs.gnu.org
> Date: Sun, 01 Nov 2020 13:06:00 +0100
> 
> Eli Zaretskii <eliz@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?

bug#44303: 28.0.50; json-pretty-print-buffer creates spurious lock file

[Simen Heggestøyl]

Eli Zaretskii <eliz@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:

{
}

bug#44303: 28.0.50; json-pretty-print-buffer creates spurious lock file

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@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

bug#44303: 28.0.50; json-pretty-print-buffer creates spurious lock file

[Eli Zaretskii]

> From: Simen Heggestøyl <simenheg@runbox.com>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  44303@debbugs.gnu.org
> Date: Mon, 09 Nov 2020 09:24:03 +0100
> 
> Eli Zaretskii <eliz@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.

bug#44303: 28.0.50; json-pretty-print-buffer creates spurious lock file

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: simenheg@runbox.com,  44303@debbugs.gnu.org
> Date: Mon, 09 Nov 2020 15:03:07 +0100
> 
> Eli Zaretskii <eliz@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.

bug#44303: 28.0.50; json-pretty-print-buffer creates spurious lock file

[Simen Heggestøyl]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Simen Heggestøyl <simenheg@runbox.com>
>> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  44303@debbugs.gnu.org
>> Date: Mon, 09 Nov 2020 09:24:03 +0100
>>
>> Eli Zaretskii <eliz@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!

bug#44303: 28.0.50; json-pretty-print-buffer creates spurious lock file

[Eli Zaretskii]

> Date: Mon, 09 Nov 2020 17:58:12 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: larsi@gnus.org, 44303@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.