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

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

>> --- a/lisp/dired.el
>> +++ b/lisp/dired.el
>> @@ -1306,7 +1306,7 @@ dired-internal-noselect
>>  	 ;; Note that buffer already is in dired-mode, if found.
>>  	 (new-buffer-p (null buffer)))
>>      (or buffer
>> -        (setq buffer (create-file-buffer (directory-file-name dirname))))
>> +        (setq buffer (create-file-buffer dirname)))
>
> This seems to imply that callers of create-file-buffer will now have
> to remember to ensure the argument ends in a slash if it is the name
> of a directory.

Which callers are you thinking of?

I think the fact that the callers get to control this regardless of
whether there is a file or directory by that name is one of the best
part of this change.

> If so, I'd prefer that create-file-buffer did that internally, when
> its argument is a directory.

What would be the benefit?

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


        Stefan