GNU bug report logs - #62732
29.0.60; uniquify-trailing-separator-p affects any buffer whose name matches a dir in CWD

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: sbaugh <at> catern.com, 62732 <at> debbugs.gnu.org
Subject: bug#62732: 29.0.60; uniquify-trailing-separator-p affects any buffer whose name matches a dir in CWD
Date: Mon, 10 Jul 2023 15:18:48 -0400

>> > Callers shouldn't know to much about the internals of the callee.
>> 
>> Indeed: currently `create-file-buffer` doesn't pay attention to the file
>> system at all, it just creates a buffer with a name based on the
>> FILENAME that's passed.  Spencer's patch just offers more control to the
>> callers by making `create-file-buffer` respect the choice of the callers
>> (whether they used a file name or a dire name, which is an important
>> distinction in Emacs's file name APIs, not just here).
>> 
>> There's no need for the callers to know about the internals of
>> the callee.  If they call `create-file-buffer` with /foo/bar/baz the
>> buffer will be called "baz" and if they call it with /foo/bar/baz/ the
>> buffer will be called "baz/" (depending on
>> `uniquify-trailing-separator-p`, of course).
>> It's the most natural/obvious semantics.
>
> Wasn't the fact that the trailing slash was absent part of the reason
> for the bug this tries to fix?  If so, then this is not just "if you
> want it, use it", is it?

No, `create-file-buffer` used to throw away the trailing slash, rather
than make use of this information.  Not sure why Dired bothered to
remove the tailing slash when calling it, maybe because a long time ago
`create-file-buffer` had a bug if the name had a trailing slash.


        Stefan

Previous Next

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