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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: juri@linkov.net,  39190@debbugs.gnu.org,  felician.nemeth@gmail.com
> Date: Wed, 29 Jan 2020 16:33:31 -0500
> 
> > 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 ;-)

What is the problem of the first alternative wrt dir-locals?  I don't
think I understand that.

> > 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.

set-auto-mode looks on other mode-determining stuff, before looking at
the file name.

> > 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.

Yes, but having leading directories in it feels... unclean, even more
than just having this variable.

> > 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.

Non-nil doesn't mean it's a string.