bug#74208: 31.0.50; minibuffer read-file-name-default mutates global value of default-directory incorrectly

[Madhu]

*  Eli Zaretskii <eliz@gnu.org> <8634izk7ky.fsf@gnu.org>
Wrote on Sat, 07 Dec 2024 14:20:45 +0200
> Ping! Do we want to do anything about this issue?

is "Keep it open" an option? :)

call-process calls get_current_directory (which you exhibited) which
in turn calls unhandled-file-name-directory, for which the
documentation is

```
"unhandled-file-name-directory"

Return a directly usable directory name somehow associated with \
FILENAME.
A `directly usable' directory name is one that may be used without the
intervention of any file name handler.
If FILENAME is a directly usable file itself, return
\(file-name-as-directory FILENAME).
If FILENAME refers to a file which is not accessible from a local process,
then this should return nil.
The `call-process' and `start-process' functions use this function to
get a current directory to run processes in.
```

(let ((default-directory "https://www.gnu.org/";))
  (unhandled-file-name-directory default-directory))
=> "https://www.gnu.org/";

call-process is bound to fail.

I still haven't gotten around to trying url completions (I use the
implementation in emacs-w3m w3m-urls-completion) but assuming it is
going to useful, perhaps the completion mechanism should work off a
new url-default-directory rather than default-directory if needed.