From: Michael Albinus <michael.albinus@gmx.de>
To: "Jay Berkenbilt" <ejb@ql.org>
Cc: Glenn Morris <rgm@gnu.org>, Lars Ingebrigtsen <larsi@gnus.org>,
53207@debbugs.gnu.org
Subject: bug#53207: 28.0.91; create-lockfiles nil breaks file change detection
Date: Fri, 14 Jan 2022 15:26:18 +0100 [thread overview]
Message-ID: <87fspqz94l.fsf@gmx.de> (raw)
In-Reply-To: <b2fdb89f-e79b-4d37-be32-bd233e49282f@www.fastmail.com> (Jay Berkenbilt's message of "Thu, 13 Jan 2022 10:47:21 -0500")
"Jay Berkenbilt" <ejb@ql.org> writes:
Hi Jay,
> On Thu, Jan 13, 2022, at 9:02 AM, Eli Zaretskii wrote:
>> > Date: Thu, 13 Jan 2022 08:11:34 -0500
>> > From: "Jay Berkenbilt" <ejb@ql.org>
>> > Cc: 53207@debbugs.gnu.org
>> >
>> > For my edification, can you explain how the 27.2 behavior of noticing
>> > when a file's contents had changed immediately is not adequate without
>> > lockfiles?
>>
>> First, Emacs 27 wasn't looking at the file's contents, it was looking
>> at the file's modification time.
>
> My original recipe for reproducing the issue demonstrated that, after
> "touch file", you can continue editing freely and save, but after
> changing the contents, you can't. I don't remember when this first
> changed, maybe emacs 27 or 26. For ages before that, it was
> modification time. I remember noticing when updating the modtime
> without changing the content stopped triggering that. I was delighted.
>
> It is definitely the case that just updating the modification time on
> emacs 27.2 does not trigger this. You can try it. In emacs -Q, edit a
> file and save. From the shell, touch the file. No continue editing the
> file and save again. No warning. At least this is the case on my
> Ubuntu Linux 20.04 system with emacs compiled from source.
Same here. In lock_file of Emacs 27, there is the check
--8<---------------cut here---------------start------------->8---
if (!NILP (subject_buf)
&& NILP (Fverify_visited_file_modtime (subject_buf))
&& !NILP (Ffile_exists_p (fn)))
call1 (intern ("userlock--ask-user-about-supersession-threat"), fn);
--8<---------------cut here---------------end--------------->8---
It checks the file modification time. But then, if changed, it calls
userlock--ask-user-about-supersession-threat, which also checks the file
contents before warning. Therefore, a simple touch doesn't trigger the
user question.
>> > It seems to me that there are two separate issues here. A lock file
>> > would enable you to immediately notice if a user on a *different
>> > system* is in the process of editing a file and has unsaved changes.
>>
>> No, it also works when the same user on the same system edited the
>> file from another Emacs session. That is a valid use case: some
>> people start more than a single Emacs session on the same system.
>
> Granted. Of course it doesn't protect against another very common use
> case, which is people opening the same file in emacs and
> simultaneously in something like VS Code or another IDE. I know
> developers that work this way day in and day out -- they use emacs for
> most of their editing but hop over to an IDE to take advantage of
> project-wide integrations, better test integration, a more advanced
> debugger, or better out-of-the-box functionality with their
> programming language or environment of choice. So lock files remain a
> solution that only works in an emacs-only environment, while noticing
> that the file's modification time has changed is universal, and
> noticing that a file's content has changed is a great advancement over
> just noticing modtime since it allows for workflows like git rebase.
>
>> > On the other hand, the other behavior I'm talking about allows you to
>> > notice immediately when you begin editing if the file on disk has
>> > become out of sync with the buffer contents.
>>
>> That part is done when you save the buffer. It is unaffected by
>> create-lockfiles.
>
> It is also done when you start editing a buffer, as shown in my original
> message. Really. Try it.
Sure. That's because there's no visited file modification time yet for
that buffer.
In Emacs 28, the check above has been extended to
--8<---------------cut here---------------start------------->8---
if (!NILP (subject_buf)
&& NILP (Fverify_visited_file_modtime (subject_buf))
&& !NILP (Ffile_exists_p (fn))
&& current_lock_owner (NULL, lfname) != I_OWN_IT)
call1 (intern ("userlock--ask-user-about-supersession-threat"), fn);
--8<---------------cut here---------------end--------------->8---
So it checks also the owner of the lock file. This makes only sense, if
create-lockfiles is non-nil; otherwise there is no lock file owner ...
I agree with Eli, that the current behavior in Emacs 28 is
consistent. Since this is an incompatible change, we shall document
it. The Emacs 28 manual says
--8<---------------cut here---------------start------------->8---
You can prevent the creation of lock files by setting the variable
‘create-lockfiles’ to ‘nil’. *Caution:* by doing so you will lose the
benefits that this feature provides.
--8<---------------cut here---------------end--------------->8---
Maybe it shall be more explicit saying, that also detection of changing
the modification time is lost when create-lockfiles is nil.
etc/NEWS is silent about this, it should explain this subtle change as well.
Best regards, Michael.
next prev parent reply other threads:[~2022-01-14 14:26 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-12 14:30 bug#53207: 28.0.91; create-lockfiles nil breaks file change detection Jay Berkenbilt
2022-01-12 17:26 ` Eli Zaretskii
2022-01-12 20:07 ` Jay Berkenbilt
2022-01-12 20:45 ` Eli Zaretskii
2022-01-12 21:35 ` Jay Berkenbilt
2022-01-13 6:43 ` Eli Zaretskii
2022-01-13 13:06 ` Jay Berkenbilt
2022-01-12 18:13 ` Glenn Morris
2022-01-12 18:41 ` Philipp Stephani
2022-01-13 10:54 ` Eli Zaretskii
2022-01-13 13:11 ` Jay Berkenbilt
2022-01-13 13:24 ` Philipp Stephani
2022-01-13 14:02 ` Eli Zaretskii
2022-01-13 15:47 ` Jay Berkenbilt
2022-01-14 14:26 ` Michael Albinus [this message]
2022-01-14 14:43 ` Eli Zaretskii
2022-01-14 16:11 ` Glenn Morris
2022-01-14 16:44 ` Eli Zaretskii
2022-01-15 8:06 ` Lars Ingebrigtsen
2022-01-15 8:16 ` Lars Ingebrigtsen
2022-01-15 9:23 ` Eli Zaretskii
2022-01-27 17:19 ` Eli Zaretskii
2022-01-28 13:42 ` Lars Ingebrigtsen
2022-01-28 14:30 ` Eli Zaretskii
2022-01-28 14:56 ` Michael Albinus
2022-01-28 15:16 ` Eli Zaretskii
2022-01-29 10:53 ` Michael Albinus
2022-01-29 10:57 ` Eli Zaretskii
2022-02-03 13:31 ` Michael Albinus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87fspqz94l.fsf@gmx.de \
--to=michael.albinus@gmx.de \
--cc=53207@debbugs.gnu.org \
--cc=ejb@ql.org \
--cc=larsi@gnus.org \
--cc=rgm@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).