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

[Eli Zaretskii]

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

More to the point, the verification of the file's modification time
that is now disabled when create-lockfiles is nil is part of detecting
editing collisions, so when the user opts out of it, it makes sense
not to detect _any_ collisions, including those detectable by
verifying that the file wasn't modified since last visited or saved.
The use of lockfiles is an implementation detail, and the fact that we
only need it for 90% of the feature, not for 100%, is not significant
enough IMO.

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

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