bug#39190: 28.0.50; two buffers with same buffer-file-name (diff-syntax-fontify-props)

[Stefan Monnier <monnier@iro.umontreal.ca>]

> But then did you consider alternatives to yet another magic
> buffer-local variable?  Two possibilities come to mind:
>
>  . change set-auto-mode to accept another optional argument, the file
>    name to use to look up the mode
>
>  . perform look up of auto-mode-alist, then invoke the mode directly

The issue is that we also want to obey dir-locals and both above options
seem to become more invasive once we try and handle those (the first
above option is the first one I proposed, since I prefer
lexically-scoped args over dynamically-scoped vars ;-)

> Also, setting the pseudo-filename is not guaranteed to turn on the
> mode according to that file name.  Not sure if this matters in these
> cases.

Not sure what you mean here.

> And finally, I cannot say that I like this part of the patch:
>
>   @@ -3459,6 +3460,8 @@ hack-local-variables-confirm
>        (let ((name (cond (dir-name)
> 			(buffer-file-name
> 			 (file-name-nondirectory buffer-file-name))
>   +		      (buffer-file-name-for-mode
>   +		       (file-name-nondirectory buffer-file-name-for-mode))
> 			((concat "buffer " (buffer-name)))))
> 	    (offer-save (and (eq enable-local-variables t)
> 			     unsafe-vars))
>
> If buffer-file-name-for-mode is not really a file name, we shouldn't
> call file-name-nondirectory on it.

It is supposed to be a file name.  It's only that the buffer is not
supposed to be the buffer corresponding to that file.

> If nothing else, it will signal an
> error if buffer-file-name-for-mode is nil.

That code is predicated on `buffer-file-name-for-mode` being
non-nil, AFAICT, so I think we're OK in this regard.


        Stefan