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: sbaugh@catern.com,  62732@debbugs.gnu.org
>> Date: Mon, 10 Jul 2023 22:55:23 -0400
>> 
>> >> No, `create-file-buffer` used to throw away the trailing slash, rather
>> >> than make use of this information.
>> 
>> [ And instead uniquify had to try and recover that information by checking
>>   the file-system.  ]
>> 
>> >> 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?
>> 
>> Because we do want Dired to tell `create-file-buffer` that this is
>> a directory and it should thus obey `uniquify-trailing-separator-p`.
>
> When will we NOT want to tell create-file-buffer that the file is a
> directory?  Your original response, viz.:
>
>> 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.
>
> seemed to indicate that there are cases where we would not want
> create-file-buffer to know that, but I suspect that we will always
> want, because otherwise uniquify will not work in those cases, and
> Spencer will report a bug.
>
> My comments assumed that indeed we will (almost) always want to tell
> create-file-buffer this is a directory.

One contribution, not intended to be exhaustive of all use cases, and
not intended to be definitively a good idea: a user could want opened
tar files with their file listing view to have a trailing slash, even
though they aren't actually directories.

And with my approach that is possibly just by running
file-name-as-directory over the name before passing it to
create-file-buffer.