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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Madhu <enometh <at> meer.net>
Cc: monnier <at> iro.umontreal.ca, 74208 <at> debbugs.gnu.org
Subject: bug#74208: 31.0.50; minibuffer read-file-name-default mutates global value of default-directory incorrectly
Date: Sun, 10 Nov 2024 13:26:10 +0200

> Date: Sun, 10 Nov 2024 16:47:17 +0530 (IST)
> Cc: monnier <at> iro.umontreal.ca, 74208 <at> debbugs.gnu.org
> From: Madhu <enometh <at> meer.net>
> 
> *  Eli Zaretskii <eliz <at> gnu.org> <86ed3jl63j.fsf <at> gnu.org>
> Wrote on Sun, 10 Nov 2024 12:45:52 +0200
> >> I was evaluating it under edebug after calling edebug-defun on
> >> read-file-name-default, and ivoking (ffap) on the url.
> >>
> >> It returns the argument with or without the second parameter to
> >> expand-file-name, and I was hoping I could count on this behaviour to
> >> separate the urls from the files.
> >>
> >> The behaviour of expand-file-name is apparenlty modified when it comes
> >> to read-file-name-default, but I can't spot what's going on. ?????
> >
> > Perhaps because TRAMP was loaded?
> It's because of the call to
>  (ffap-read-file-or-url "foo" "https://example.com/")
> 
> which roughly does the equivalent of
> 
> (let ((file-name-handler-alist
>        (cl-adjoin (cons ffap-url-regexp #'ffap--url-file-handler)
> 		  file-name-handler-alist)))
>   (expand-file-name "https://example.com" "~"))
> 
> Maybe the idea will still work?

The idea being not to bind default-directory to the URL?  Doesn't ffap
need that?  If not, why does it override the file handlers?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.