Eli Zaretskii <eliz@gnu.org> writes:

>> From: Matt Armstrong <matt@rfc20.org>
>> Date: Sun, 21 Feb 2021 20:18:44 -0800
>> 
>> Subject: [PATCH 1/4] Remove unecessary (unlock-buffer) calls.
>> 
>> * lisp/type-break.el (type-break-mode): Remove an (unlock-buffer) call
>> implied by (set-buffer-modified nil).
>> * lisp/simple.el (primitive-undo): ditto.
>
> My reading of the code is that the above is true only if
> inhibit-modification-hooks is nil.  Otherwise, these calls are not
> no-ops.

Thanks, good catch.  I think the change to type-break.el is probably
fine, but I will drop it for now.  In simple.el I just removed the
unecessary fboundp check (new patch attached).


>> --- a/lisp/files.el
>> +++ b/lisp/files.el
>> @@ -6234,11 +6234,8 @@ revert-buffer-insert-file-contents--default-function
>>               "Cannot revert unreadable file %s")
>>             file-name))
>>     (t
>> -    ;; Bind buffer-file-name to nil
>> -    ;; so that we don't try to lock the file.
>> -    (let ((buffer-file-name nil))
>> -      (or auto-save-p
>> -          (unlock-buffer)))
>> +    (unless auto-save-p
>> +      (unlock-buffer))
>
> And here, I think we just forgot to update the Lisp code when
> unlock-buffer started to look at buffer-file-truename instead of
> buffer-file-name.  But otherwise, I see no reason why we should remove
> the call to unlock-buffer; what did I miss?

This is some very old code.

When originally written the `unlock-buffer' was a nop because it was
well before file-buffer-truename existed -- the let bind disabled it.
The let bind was intended to prevent locking the buffer by
`erase-buffer'.  See Roland's commit below, which is the first commit
for this file that we've got.


b4da00e92a0 (Roland McGrath      1991-07-19 1804)

;; Bind buffer-file-name to nil
;; so that we don't try to lock the file.
(let ((buffer-file-name nil))
  (or auto-save-p
      (unlock-buffer))
  (erase-buffer))
(insert-file-contents file-name (not auto-save-p))))


A few years later Richard moved the erase logic to insert-file-contents,
but left the no-op call to unlock-buffer.  Note that the comment no
longer makes sense.

f9456b0a5b5 (Richard M. Stallman 1994-02-17 2020)

;; Bind buffer-file-name to nil
;; so that we don't try to lock the file.
(let ((buffer-file-name nil))
  (or auto-save-p
      (unlock-buffer))
(insert-file-contents file-name (not auto-save-p)
                      nil nil t)))


insert-file-contents has logic to unlock the buffer. I must admit that I
don't understand how that logic works.

When unlock-buffer switched to using buffer-file-tempfile the
unlock-buffer call here became active for the first time, probably by
accident?  Removing it now is a possible behavior change, but it
restores the original behavior.

I did a manual test.  I edited a file, then changed the file outside
emacs, then ran revert-buffer.  The file's lock file was still removed,
even with the patch below applied.