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

[Spencer Baugh <sbaugh@janestreet.com>]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: Spencer Baugh <sbaugh@janestreet.com>,  sbaugh@catern.com,
>>   62732@debbugs.gnu.org
>> Date: Wed, 12 Jul 2023 09:04:40 -0400
>> 
>> I'm not sure what to make of this discussion.
>> 
>> The issue at hand is the following: `create-file-buffer` needs to know
>> if the filename it receives is for a directory or not so it can decide
>> whether the buffer name should end in / or not according to
>> `uniquify-trailing-separator-p`.
>> 
>> I can see 3 ways to provide this info:
>> 
>> 1- use `file-directory-p`.
>> 2- add a boolean `directory` argument to `create-file-buffer`.
>> 3- use the presence of a trailing directory separator in the filename.
>> 
>> Those 3 are very close to each other, in practice, so we're pretty much
>> in bikeshed territory.
>> 
>> My preference is (3) first, (2) second, and (1) last.
>
> I prefer (1), because it avoids requesting the callers to remember to
> ensure that every directory ends in a slash.
>
> The trailing-slash semantics is indeed pretty much standard, but only
> in interactive usage (where it is made easier by the file-name
> completion machinery, both in Emacs and in other programs that ask
> users to type file names).  And even in interactive usage it is
> problematic: recall the many complaints when we started requiring the
> slash in copy-file and such likes.  Here we are talking about a
> low-level function, not an interactive command, which then places this
> burden on the callers, and I worry that many of them will not pay
> attention to this subtlety, and will cause subtle bugs, because AFAIK
> the uniquify modes where that is important are rarely used, and thus
> such problems could go undetected for many years.

Not to prelong the discussion any further, but one more detail: This
uniquify-trailing-separator-p variable really IMO should be a dired
variable, since it only affects dired buffer naming (at least in core
Emacs, for now).  This behavior has really nothing to do with uniquify.
So IMO it should never have been a uniquify variable in the first place,
and in an earlier version of my patch I moved the variable to dired and
obsoleted the old one.

I dropped that move because it wasn't particularly necessary and could
be done in a followup, but of these three options, 2 and 3 work much
better with moving this variable to dired, because only 2 and 3 let
dired control this without affecting other packages.  Option 1 forces
the same behavior on every package.  I guess we could still have that as
a dired variable, but it seems weirder.

(As a dired variable, it could control just "does dired pass a directory
name or a file name to create-file-buffer?", and create-file-buffer
could always include the trailing slash when it sees a directory name)