GNU bug report logs - #36830
26.2; find-file-visit-truename is not honored as file local variable

Previous Next

Package: emacs;

Reported by: Gustavo Barros <gusbrs.2016 <at> gmail.com>

Date: Sun, 28 Jul 2019 15:22:01 UTC

Severity: normal

Found in version 26.2

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Gustavo Barros <gusbrs.2016 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 36830 <at> debbugs.gnu.org
Subject: bug#36830: 26.2; find-file-visit-truename is not honored as file local variable
Date: Fri, 23 Aug 2019 18:38:40 -0300
Hi Eli, Hi Lars,

On Fri, Aug 23 2019, Eli Zaretskii wrote:

>> From: Lars Ingebrigtsen <larsi <at> gnus.org>
>> Date: Fri, 23 Aug 2019 20:59:55 +0200
>> Cc: 36830 <at> 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.

I admittedly reported this from a user perspective, and do not fully 
grasp what is going on in this case.  But I think I can add something 
here if I point that `vc-follow-symlinks` does work as a file local 
variable.  Maybe I’m wrong in comparing these two variables, but if not, 
this could both provide some approach that works for this purpose, and 
could perhaps reduce the concerns raised by Eli.

I may also add that I would hardly set `find-file-visit-truename` 
globally, but I would find it useful locally (I don’t claim to be any 
reference in this respect though).  Furthermore, if the race mentioned 
by Eli does prove to be insurmountable, and if there is any difference 
between setting this as "file-local" or as "dir-local", the latter could 
prove useful even if the former could not be maintained.  (I don’t know 
if dir-local variables are set before the file is actually visited, but 
that is what I have in mind in mentioning this.  If that is the case, 
the race might be thus circumvented.)

Best,
Gustavo.




This bug report was last modified 5 years and 301 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.