bug#53207: 28.0.91; create-lockfiles nil breaks file change detection

["Jay Berkenbilt" <ejb@ql.org>]

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.

> > 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.