From: Lars Ingebrigtsen <larsi@gnus.org>
Date: Fri, 23 Aug 2019 20:59:55 +0200
Cc: 36830@debbugs.gnu.org
(if find-file-visit-truename
(setq buffer-file-name (expand-file-name
buffer-file-truename)))
[...]
(after-find-file error (not nowarn)))
`after-find-file' is the function that interprets the file local
variables, so we're setting the buffer file name before we've set
that
variable locally.
One option would be to re-check the variable after `after-find-file',
but that seems a bit hacky.
Any opinions?
I don't think this variable was designed to be set from file-local
variables block. Visiting a file and naming its buffer are two racy
actions, and where there's a race there will be chicken-and-egg type
of problems.
--- a/lisp/files.el
+++ b/lisp/files.el
@@ -2413,7 +2413,11 @@ find-file-noselect-1
(setq buffer-file-coding-system 'no-conversion)
(set-buffer-major-mode buf)
(setq-local find-file-literally t))
- (after-find-file error (not nowarn)))
+ (after-find-file error (not nowarn))
+ ;; In case `find-file-visit-truename' is set as a file-local
+ ;; variable, recompute the buffer file name.
+ (when find-file-visit-truename
+ (setq buffer-file-name (expand-file-name
buffer-file-truename))))
I expect such renaming to cause future bugs, FWIW. Or maybe not, but
this is beyond hacky, IMO.
Maybe we should just document that this variable cannot be file-local.