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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: sbaugh@catern.com,  62732@debbugs.gnu.org
> 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.

So why the need for the change in dired.el?