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

[Michael Albinus]

Madhu <enometh@meer.net> writes:

Hi,

> ```
> "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/";

unhandled-file-name-directory expects, that special constructs in
FILENAME are handled via a file name handler. Per default,
"https://www.gnu.org/"; is not covered by a file name handler, so I
believe it is a non-valid value for default-directory.

See

--8<---------------cut here---------------start------------->8---
(progn
  (url-handler-mode)
  (let ((default-directory "https://www.gnu.org/";))
    (unhandled-file-name-directory default-directory)))
=> nil
--8<---------------cut here---------------end--------------->8---

Whether nil is a proper value to be returned is questionable. However,
call-process and friends are able to handle a nil default-directory.

> 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.

We don't need a new url-default-directory. We must ensure that
url-handler-mode is activated (temporarily) for such use cases.

Best regards, Michael.