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

[Madhu <enometh@meer.net>]

*  Eli Zaretskii <eliz@gnu.org> <86msi7ljb0.fsf@gnu.org>
Wrote on Sun, 10 Nov 2024 08:00:35 +0200
>> --- a/lisp/minibuffer.el
>> +++ b/lisp/minibuffer.el
>> @@ -3668,10 +3668,11 @@ read-file-name-default
>>                    ;; changing `default-directory' in the current buffer,
>>                    ;; we don't let-bind it.
>>                    (let ((dir (file-name-as-directory
>> -                              (expand-file-name dir))))
>> +                              (expand-file-name dir)))
>> +                        (default-directory (if (file-name-absolute-p dir)
>> +                                               dir default-directory)))
> You probably meant to use let*, right?

Oops. yes, of course.

> But anyway, I don't understand the logic: expand-file-name always
> returns an absolute file name, so the test will always succeed.  What
> did I miss?

for the example in the thread,
ffap.el:(ffap-read-file-or-url) calls read-file-name-default, via
              (funcall #'read-file-name-default prompt guess guess) =>

  read-file-name-default("Find file or URL: " "http://example.com" "http://example.com")

(read-file-name-default PROMPT &optional DIR DEFAULT-FILENAME
 MUSTMATCH INITIAL PREDICATE)

The problem is that the parameter DIR == "http://example.com" was
getting bound to default-directory with undesirable results. DIR a url
not a file name but a url. and since expand-file-name behaves like
this:

(expand-file-name "http://example.com" "~") ->  "http://example.com"

it can probably be used to determine that DIR is not a legit filename
and default directory should not be bound to it. I don't think it has
any consequences for the completion-system completion via
read-file-name, which would not work anyway (and completing urls in
this context say matching against a history list of urls would not
make sense either)