bug#52395: 27.2; Expansion of DIR arg of `dired-buffers-for-dir'

[Drew Adams <drew.adams@oracle.com>]

This bug report is in the form of a question.  Shouldn't this function
expand the DIR argument using `expand-file-name' (e.g. with
`default-directory')?

I think the answer is "yes", but perhaps there's some good reason the
answer should be "no".

All uses of `dired-buffers-for-dir' I'm aware of call `expand-file-name'
on the directory passed as arg.

If you instead pass, say, "~/some/dir/", then a Dired buffer for that
directory won't be found.  To me, that seems like a bug.  The "problem"
is that the code just uses `assoc' to look up the given DIR argument in
the value of `dired-subdir-alist', and entries in that alist have
absolute (i.e., expanded) dir names as their cars.

At the very least, the doc should tell you about the gotcha - it should
tell you to expand the DIR arg before calling.

I'd propose changing the first line of the `dired-buffers-for-dir' code
from this:

  (setq dir  (file-name-as-directory dir))

to this:

  (setq dir  (expand-file-name (file-name-as-directory dir)))

That way, there's no need for callers to themselves expand the dir name.

(A question is whether `file-truename' should be used instead of
`expand-file-name'.  I guess not.)

Such a code change shouldn't change the behavior of any existing code,
since that seems to always use `expand-file-name' before calling
`dired-buffers-for-dir'.

If this code change is made then it would be good to also change the
doc to say that DIR is expanded relative to `default-directoy'.  Code
that needs a name expanded properly relative to some other directory will
then be sure to expand the name before calling `dired-buffers-for-dir'.
___

If you don't agree to such a code change, fine.  But in that case I
suggest that the doc of `dired-buffers-for-dir' say explicitly that
argument DIR needs to be an expanded absolute file name.  The doc needs
to explicitly say "expanded", because `file-absolute-p' doesn't test for
this meaning of "absolute" file name - the name cannot use `~' for a
home directory.

In GNU Emacs 27.2 (build 1, x86_64-w64-mingw32)
 of 2021-03-26 built on CIRROCUMULUS
Repository revision: deef5efafb70f4b171265b896505b92b6eef24e6
Repository branch: HEAD
Windowing system distributor 'Microsoft Corp.', version 10.0.19042
System Description: Microsoft Windows 10 Pro (v10.0.2009.19042.1348)

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
 'configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install 'CFLAGS=-O2 -static''