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

Previous Next

Full log

Message #68 received at 39190 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 39190 <at> debbugs.gnu.org, felician.nemeth <at> gmail.com, juri <at> linkov.net
Subject: Re: bug#39190: 28.0.50; two buffers with same buffer-file-name
 (diff-syntax-fontify-props)
Date: Thu, 30 Jan 2020 16:17:54 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: juri <at> linkov.net,  39190 <at> debbugs.gnu.org,  felician.nemeth <at> 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.

Previous Next

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