From: Matt Armstrong <matt@rfc20.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 46701@debbugs.gnu.org
Subject: bug#46701: [PATCH] small cleanups related to `unlock-buffer'
Date: Mon, 22 Feb 2021 16:56:44 -0800 [thread overview]
Message-ID: <m2lfbfr48j.fsf@matts-mbp-2016.lan> (raw)
In-Reply-To: <831rd8vzim.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 2951 bytes --]
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.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Remove-unecessary-unlock-buffer-call.patch --]
[-- Type: text/x-patch, Size: 947 bytes --]
From 3b569a6b9139d2b350745bebc64db506728cf994 Mon Sep 17 00:00:00 2001
From: Matt Armstrong <matt@rfc20.org>
Date: Mon, 22 Feb 2021 16:40:05 -0800
Subject: [PATCH 1/2] Remove unecessary unlock-buffer call.
* lisp/files.el (revert-buffer-insert-file-contents--default-function):
Remove vestigial call to `unlock-buffer'.
---
lisp/files.el | 5 -----
1 file changed, 5 deletions(-)
diff --git a/lisp/files.el b/lisp/files.el
index 68e883513c..b5d92cd841 100644
--- a/lisp/files.el
+++ b/lisp/files.el
@@ -6234,11 +6234,6 @@ 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)))
(widen)
(let ((coding-system-for-read
;; Auto-saved file should be read by Emacs's
--
2.30.0
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-Assume-unlock-buffer-is-always-bound.patch --]
[-- Type: text/x-patch, Size: 980 bytes --]
From dc9cc451e0ab6a84d839f3ed9d1b552da3c43373 Mon Sep 17 00:00:00 2001
From: Matt Armstrong <matt@rfc20.org>
Date: Mon, 22 Feb 2021 16:41:44 -0800
Subject: [PATCH 2/2] Assume unlock-buffer is always bound.
* lisp/simple.el (primitive-undo): Assume unlock-buffer is always
bound.
---
lisp/simple.el | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/lisp/simple.el b/lisp/simple.el
index 1dfc3374ad..c4062d97cc 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -3043,8 +3043,7 @@ primitive-undo
(and (consp time)
(equal (list (car time) (cdr time))
(visited-file-modtime))))
- (when (fboundp 'unlock-buffer)
- (unlock-buffer))
+ (unlock-buffer)
(set-buffer-modified-p nil)))
;; Element (nil PROP VAL BEG . END) is property change.
(`(nil . ,(or `(,prop ,val ,beg . ,end) pcase--dontcare))
--
2.30.0
next prev parent reply other threads:[~2021-02-23 0:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-22 4:18 bug#46701: [PATCH] small cleanups related to `unlock-buffer' Matt Armstrong
2021-02-22 16:27 ` Eli Zaretskii
2021-02-23 0:56 ` Matt Armstrong [this message]
2021-02-26 0:45 ` Stefan Kangas
2021-02-27 14:22 ` Eli Zaretskii
2021-02-27 14:24 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2lfbfr48j.fsf@matts-mbp-2016.lan \
--to=matt@rfc20.org \
--cc=46701@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.