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

[Eli Zaretskii]

> Date: Wed, 12 Jan 2022 16:35:15 -0500
> From: "Jay Berkenbilt" <ejb@ql.org>
> Cc: 53207@debbugs.gnu.org
> 
> > > > My suggestion is to stop setting create-lockfiles to a nil value.  Why
> > > > is the non-nil value a problem?
> > > 
> > > Emacs lockfiles are dangling symbolic links. Some tools and systems don't
> > > like those.
> > 
> > Isn't that the reason we introduced lock-file-name-transforms?
> 
> Perhaps so, but this misses the point.

My point was to say that if you want collision detection, you should
turn on create-lockfiles.  You said this could cause problems with
some tools, and I then pointed out that Emacs 28 has a new feature to
help you solve that side effect, so that you could use locking again.

> I am pointing out at there is an undocumented,
> perhaps undesirable change of behavior that needs to be either fixed or 
> documented.

I understand, but that's a separate, albeit related, issue.  I was
trying to help you to get collision detection back.  Your original
report seemed to ask how to do that, so I tried to answer that part.

> If the change of behavior is intentional, then it should be documented.

We are discussing this, and will document if that's the conclusion.

> It just seems strange that emacs is perfectly capable of detecting when a 
> file was changed
> outside of emacs without a lockfile but doesn't do this check if it's not 
> also creating lockfiles.

Once again, this is not about the lockfiles, this is about the entire
feature of detection of editing collisions.  The variable's name is a
misnomer.