bug#44822: 27.1; Regression in `ffap-read-file-or-url'

bug#44822: 27.1; Regression in `ffap-read-file-or-url'

[Drew Adams]

`ffap-read-file-or-url' now reads a URL as a file name, truncating to
remove a prefix such as http:/.  Prior to Emacs 27, it correctly
returned the URL.

If point is not on a URL, then the guess is nil.  The user is prompted
(as before) with the default directory as default.  If the user rejects
that default value and replaces it by a URL (e.g. yanking), then
`ffap-read-file-or-url' should just return that URL, as it has always
done.  In Emacs 27, it instead tries to handle it as a file name,
removing the prefix up to the first `/' before a non-/ char.

emacs -Q

;; With point not on a URL or file name:

(ffap-read-file-or-url "URL: " nil)

;; User is prompted, with the default-directory as default:

URL: /my/default/dir/

;; User pastes a URL after that or replaces that with a URL.

URL: /my/default/dir/http://foobar.com RET
;; or
URL: http://foobar.com RET

;; This is returned: /foobar.com

In Emacs 26.3 the URL entered by the user is returned correctly.

A main use of `read-file-or-url' is to prompt for and read a URL.  If a
user enters a URL when FFAP has not been able to guess a URL, FFAP now
just treats the input as a filename.  It treats prefix `http:/' the same
way it would treat prefix `c:' on MS Windows.

Reading a URL is maybe the main use case of `ffap-read-file-or-url'.  (There is no `ffap-read-url'.)  It's now broken.


In GNU Emacs 27.1 (build 1, x86_64-w64-mingw32)
 of 2020-08-12 built on CIRROCUMULUS
Repository revision: 86d8d76aa36037184db0b2897c434cdaab1a9ae8
Repository branch: HEAD
Windowing system distributor 'Microsoft Corp.', version 10.0.18362
System Description: Microsoft Windows 10 Pro (v10.0.1903.18362.1139)

bug#44822: 27.1; Regression in `ffap-read-file-or-url'

[Eli Zaretskii]

> Date: Mon, 23 Nov 2020 09:23:37 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> 
> `ffap-read-file-or-url' now reads a URL as a file name, truncating to
> remove a prefix such as http:/.  Prior to Emacs 27, it correctly
> returned the URL.
> 
> If point is not on a URL, then the guess is nil.  The user is prompted
> (as before) with the default directory as default.  If the user rejects
> that default value and replaces it by a URL (e.g. yanking), then
> `ffap-read-file-or-url' should just return that URL, as it has always
> done.  In Emacs 27, it instead tries to handle it as a file name,
> removing the prefix up to the first `/' before a non-/ char.
> 
> emacs -Q
> 
> ;; With point not on a URL or file name:
> 
> (ffap-read-file-or-url "URL: " nil)
> 
> ;; User is prompted, with the default-directory as default:
> 
> URL: /my/default/dir/
> 
> ;; User pastes a URL after that or replaces that with a URL.
> 
> URL: /my/default/dir/http://foobar.com RET
> ;; or
> URL: http://foobar.com RET
> 
> ;; This is returned: /foobar.com
> 
> In Emacs 26.3 the URL entered by the user is returned correctly.
> 
> A main use of `read-file-or-url' is to prompt for and read a URL.  If a
> user enters a URL when FFAP has not been able to guess a URL, FFAP now
> just treats the input as a filename.  It treats prefix `http:/' the same
> way it would treat prefix `c:' on MS Windows.
> 
> Reading a URL is maybe the main use case of `ffap-read-file-or-url'.  (There is no `ffap-read-url'.)  It's now broken.

Thierry and Stefan, these changes seem to have been done by you.  Can
you please take a look at this issue?  Would it be possible to fix
this for Emacs 27.2?

bug#44822: 27.1; Regression in `ffap-read-file-or-url'

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Thierry and Stefan, these changes seem to have been done by you.  Can
> you please take a look at this issue? 

I don't understand the changes either.

With (ffap-read-file-or-url "Url: " nil) it's now currently impossible
to enter an URL after this change:

commit 8685db187b891bcadcf61e41dea3124e4c45b7d4
Author:     Stefan Monnier <monnier@iro.umontreal.ca>
AuthorDate: Sat Nov 9 13:32:20 2019 -0500

    * lisp/ffap.el (ffap-read-file-or-url): Don't use url-file-handler

Stefan?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44822: 27.1; Regression in `ffap-read-file-or-url'

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen [2021-07-31 14:48:15] wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>> Thierry and Stefan, these changes seem to have been done by you.  Can
>> you please take a look at this issue? 
> I don't understand the changes either.
> With (ffap-read-file-or-url "Url: " nil) it's now currently impossible
> to enter an URL after this change:
>
> commit 8685db187b891bcadcf61e41dea3124e4c45b7d4
> Author:     Stefan Monnier <monnier@iro.umontreal.ca>
> AuthorDate: Sat Nov 9 13:32:20 2019 -0500
>
>     * lisp/ffap.el (ffap-read-file-or-url): Don't use url-file-handler
>
> Stefan?

Hmm... the motivation for the change is described in the comment:

      ;; FIXME: We earlier tried to make use of `url-file-handler' so
      ;; `read-file-name' could also be used for URLs, but it
      ;; introduced all kinds of subtle breakage such as:
      ;; - (file-name-directory "http://a") returning "http://a/"
      ;; - Trying to contact remote hosts with no justification
      ;; These should be fixed in url-handler-mode before we can try
      ;; using it here again.

Maybe the cure is worse than the disease,


        Stefan

bug#44822: 27.1; Regression in `ffap-read-file-or-url'

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Hmm... the motivation for the change is described in the comment:
>
>       ;; FIXME: We earlier tried to make use of `url-file-handler' so
>       ;; `read-file-name' could also be used for URLs, but it
>       ;; introduced all kinds of subtle breakage such as:
>       ;; - (file-name-directory "http://a") returning "http://a/"
>       ;; - Trying to contact remote hosts with no justification
>       ;; These should be fixed in url-handler-mode before we can try
>       ;; using it here again.

Duh; my eyes just skipped that bit.  :-/

> Maybe the cure is worse than the disease,

I had forgotten all the peculiarities that url-file-handler has -- it's
simply not a usable solution.

Perhaps somebody can come up with a much, much simpler solution for use
in `read-file-name' only -- that shouldn't be insurmountable, I think...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44822: 27.1; Regression in `ffap-read-file-or-url'

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Perhaps somebody can come up with a much, much simpler solution for use
> in `read-file-name' only -- that shouldn't be insurmountable, I think...

Sometimes that somebody is me, so this is now fixed in Emacs 28.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44822: 27.1; Regression in `ffap-read-file-or-url'

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen [2021-07-31 18:58:12] wrote:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> Hmm... the motivation for the change is described in the comment:
>>
>>       ;; FIXME: We earlier tried to make use of `url-file-handler' so
>>       ;; `read-file-name' could also be used for URLs, but it
>>       ;; introduced all kinds of subtle breakage such as:
>>       ;; - (file-name-directory "http://a") returning "http://a/"
>>       ;; - Trying to contact remote hosts with no justification
>>       ;; These should be fixed in url-handler-mode before we can try
>>       ;; using it here again.
>
> Duh; my eyes just skipped that bit.  :-/
>
>> Maybe the cure is worse than the disease,
>
> I had forgotten all the peculiarities that url-file-handler has -- it's
> simply not a usable solution.
>
> Perhaps somebody can come up with a much, much simpler solution for use
> in `read-file-name' only -- that shouldn't be insurmountable, I think...

Do you think that someone's last name could end in "olpiatto", maybe?


        Stefan

bug#44822: 27.1; Regression in `ffap-read-file-or-url'

[Madhu]

I couldn't follow the bug report as it always seemed to work for me[1],
but after the fix, if I do an M-x find-file-at-point with the point on
(say) https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44822

I get a minibuffer prompt "Find file or URL" with the default set to the
url and the point at the beginning of the url string

wheras earlier I used to get the same prompt with the point positioned
at the end of the url string.

This makes a difference if i'm using some other system like vertico


1. My defaults for ffap were
(setq ffap-foo-at-bar-prefix nil)
(setq ffap-machine-p-known 'reject)
(setq ffap-machine-p-local 'reject)
(setq ffap-machine-p-unknown 'reject)

bug#44822: 27.1; Regression in `ffap-read-file-or-url'

[Lars Ingebrigtsen]

Madhu <enometh@meer.net> writes:

> I couldn't follow the bug report as it always seemed to work for me[1],
> but after the fix, if I do an M-x find-file-at-point with the point on
> (say) https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44822
>
> I get a minibuffer prompt "Find file or URL" with the default set to the
> url and the point at the beginning of the url string

This should now be fixed.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no