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

From: Madhu <[email-masked]>
Date: Sat, 07 Dec 2024 22:53:57 +0530 (IST)

*  Eli Zaretskii <[email-masked]> <[email-masked]>
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.