default-directory in minibuffer on MS Windows

[Drew Adams]

This is an odd request, so please bear with the description.

This behavior is the same in Emacs 20-22.

If you have a standalone minibuffer frame, and you do C-x 4 f from it, then
on MS Windows the default-directory will have a form like this:
`C:\some-dir/'. Note the backslash. In other buffers the form is this:
`c:/some-dir/'.

Generally, there is no need to use backslashes as directory separators in
Emacs - it correctly interprets slashes, changing them as needed behind the
scene for the OS. However, the form with the backslash doesn't present a
problem for Emacs either, and users can use backslashes when they type
directory names (paths). If they do so, Emacs converts them, in the UI, to
slashes - during file-name completion, for example (and then it converts
them back to backslashes as needed for the OS). Emacs Windows users might
sometimes type `\' as directory separators, but Emacs always echos `/' to
them. IOW, in the Emacs UI, `/' is the standard directory separator.

So, what's the problem? No problem for Emacs, as I said. I have a library,
however, that lets users use regexp syntax in minibuffer input (including
file-name input). And they can of course use backslashes in regexps. So, my
library doesn't interpret backslashes as directory separators, even on MS
Windows. This means that with default-directory as it is in a standalone
minibuffer, completion fails, unless I do something to get around this
exception. So, I use a hack of applying `substitute-in-file-name' to
`default-directory' to get back to a slashes-only `default-directory'.

What's my request? To have `default-directory' always use slashes, not
backslashes, so I don't need to apply my ugly hack. This seems like the only
exception to the slash-as-standard-separator-in-the-UI rule, and I see no
reason for it. It seems like an oversight, to me, especially since the drive
letter is uppercase instead of lowercase (that makes no real difference, of
course) - my guess is that this particular part of the implementation was
not updated when everything was standardized on the `c:/some-dir/' form
years ago.

Most Windows users don't notice this exception: 1) most don't use standalone
minibuffers, 2) those who do don't often use `C-x 4 f' from the minibuffer
frame, and 3) it works anyway, so they don't pay attention to the slight
change in UI syntax. It took me a while to notice it, and I only did so
because of my particular setup, which blocked completion by not interpreting
`\' as a directory separator.

So, unless I'm missing something, there is no reason not to change this
exceptional behavior and always use /, not \, in default-directory.

Sorry for a long explanation of a simple and unimportant (for Emacs)
"problem" (for me).