Subject: Re: bug#36830: 26.2; find-file-visit-truename is not honored as file local variable

From: Eli Zaretskii <[email-masked]>
Date: Fri, 23 Aug 2019 23:07:51 +0300

> From: Lars Ingebrigtsen <[email-masked]>
> Date: Fri, 23 Aug 2019 20:59:55 +0200
> Cc: [email-masked]
> 
>       (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.