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

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

On Wed, Jan 12, 2022, at 3:45 PM, Eli Zaretskii wrote:
> > Date: Wed, 12 Jan 2022 15:07:32 -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. I am pointing out at there is an undocumented,
perhaps undesirable change of behavior that needs to be either fixed or documented.
If the change of behavior is intentional, then it should be documented. That said, I think
the old behavior made more sense. The old behavior seems to be that setting 
create-lockfiles to nil just makes emacs stop creating lockfiles. The new behavior seems
to be that it does other things as well. It's odd for you to tell me that I shouldn't use an
option that is provided, particularly when it used to do exactly what I wanted it to do.

All that said, if this is intentional and there is some reason to decrease the functionality
of emacs by making it impossible to turn off lockfile creation without this other side effect,
then I will add conditional code in my .emacs to turn off lockfiles if 
(not (boundp 'lock-file-name-transforms)).

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.