[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#36830: 26.2; find-file-visit-truename is not honored as file local v
bug#36830: 26.2; find-file-visit-truename is not honored as file local variable
Fri, 23 Aug 2019 23:07:51 +0300
> From: Lars Ingebrigtsen <address@hidden>
> Date: Fri, 23 Aug 2019 20:59:55 +0200
> Cc: address@hidden
> (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
> --- 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.