GNU bug report logs - #13961
24.3; ffap-url-unwrap-remote fails for remote file URIs

Previous Next

Package: emacs;

Reported by: Jens Lechtenboerger <lechten <at> wi.uni-muenster.de>

Date: Thu, 14 Mar 2013 17:27:02 UTC

Severity: minor

Found in version 24.3

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13961 in the body.
You can then email your comments to 13961 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#13961; Package emacs. (Thu, 14 Mar 2013 17:27:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jens Lechtenboerger <lechten <at> wi.uni-muenster.de>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Thu, 14 Mar 2013 17:27:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jens Lechtenboerger <lechten <at> wi.uni-muenster.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3; ffap-url-unwrap-remote fails for remote file URIs
Date: Thu, 14 Mar 2013 18:24:23 +0100
Hi there,

I’d like to access remote file URIs via ffap and ssh, e.g., /bar on
host foo via “file://foo/bar”.  However, the behavior of
ffap-url-unwrap-remote has changed from Emacs 23 to 24.

I’m using:

src/emacs -Q
(ffap-bindings)
(setq ffap-ftp-default-user nil)

In Emacs 23.4, with point in “file://foo/bar”, “C-x C-f” shows
“/foo:/bar” in  
the minibuffer, and RET retrieves the file via ssh, which is good.

In Emacs 24.3, “C-x C-f” shows “file://foo/bar”, and RET opens a
browser, which tries to access “file:///bar”, which is incorrect as
it misses the host.

The file scheme is not recognized as remote one.  Thus:
(setq ffap-url-unwrap-remote '("ftp" "file"))
Now, “C-x C-f” shows “/file:foo:/bar”, and RET leads to the error:
“Host `foo' looks like a remote host, `file' can only use the local host”

I’m not sure whether the previous result should be changed
somewhere.  Why should file only use the local host?

However, the problem can be avoided by the following version of
ffap-url-unwrap-remote.  Moreover, changing ffap-ftp-default-user is
not necessary any more.

(defun ffap-url-unwrap-remote (url)
  "Return URL as a remote file name, or nil."
  (let* ((obj    (url-generic-parse-url url))
	 (scheme (url-type obj))
	 (valid-schemes (if (listp ffap-url-unwrap-remote)
			    ffap-url-unwrap-remote
			  '("ftp")))
	 (host (url-host obj))
	 (port (url-port-if-non-default obj))
	 (user (url-user obj))
	 (filename (car (url-path-and-query obj))))
    (when (and (member scheme valid-schemes)
	       (string-match "\\`[a-zA-Z][-a-zA-Z0-9+.]*\\'" scheme)
	       (not (equal host "")))
      (concat "/"
	      (if (not (string= scheme "file"))
		  (concat scheme ":"))
	      (if user (concat user "@"))
	      host
	      (if port (concat "#" (number-to-string port)))
	      ":" filename))))

Best wishes
Jens




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#13961; Package emacs. (Thu, 14 Mar 2013 22:00:02 GMT) Full text and rfc822 format available.

Message #8 received at 13961 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Jens Lechtenboerger <lechten <at> wi.uni-muenster.de>
Cc: 13961 <at> debbugs.gnu.org
Subject: Re: bug#13961: 24.3; ffap-url-unwrap-remote fails for remote file URIs
Date: Thu, 14 Mar 2013 22:57:34 +0100
Jens Lechtenboerger <lechten <at> wi.uni-muenster.de> writes:

> Hi there,

Hi Jens,

> I’d like to access remote file URIs via ffap and ssh, e.g., /bar on
> host foo via “file://foo/bar”.  However, the behavior of
> ffap-url-unwrap-remote has changed from Emacs 23 to 24.

Yes. See the NEWS file of Emacs 24.3:

--8<---------------cut here---------------start------------->8---
** The FFAP option `ffap-url-unwrap-remote' can now be a list of strings,
specifying URL types that should be converted to remote file names at
the FFAP prompt.  The default is now '("ftp").
--8<---------------cut here---------------end--------------->8---

> I’m using:
>
> src/emacs -Q
> (ffap-bindings)
> (setq ffap-ftp-default-user nil)
>
> In Emacs 23.4, with point in “file://foo/bar”, “C-x C-f” shows
> “/foo:/bar” in  
> the minibuffer, and RET retrieves the file via ssh, which is good.

In Emacs 23, ffap-url-unwrap-remote had the intention to unwrap to an
ftp file name. It uses the ange-ftp syntax "/host:/remote/path".

Tramp is bundled with Emacs 23, and it uses an extended syntax
"/method:host:/remote/path". The "method:" part is optional; in this
case the default method ("ssh" in your case) will be used.

So it did work for you due to an unintended side effect.

> In Emacs 24.3, “C-x C-f” shows “file://foo/bar”, and RET opens a
> browser, which tries to access “file:///bar”, which is incorrect as
> it misses the host.

ffap-url-unwrap-remote has been changed to handle the scheme part of the
url as Tramp method, when it is known in ffap-url-unwrap-remote. "file"
does not belong to this list by default; therefore the url is regarded
as url, and it is sent to the browser.

> The file scheme is not recognized as remote one.  Thus:
> (setq ffap-url-unwrap-remote '("ftp" "file"))
> Now, “C-x C-f” shows “/file:foo:/bar”, and RET leads to the error:
> “Host `foo' looks like a remote host, `file' can only use the local host”

In this case, you declare "file" as Tramp method. The resulting
"/file:foo:/bar" is not accepted by Tramp; it doesn't know of any method
"file".

> I’m not sure whether the previous result should be changed
> somewhere.  Why should file only use the local host?
>
> However, the problem can be avoided by the following version of
> ffap-url-unwrap-remote.  Moreover, changing ffap-ftp-default-user is
> not necessary any more.
>
> (defun ffap-url-unwrap-remote (url)
>   "Return URL as a remote file name, or nil."
>   (let* ((obj    (url-generic-parse-url url))
> 	 (scheme (url-type obj))
> 	 (valid-schemes (if (listp ffap-url-unwrap-remote)
> 			    ffap-url-unwrap-remote
> 			  '("ftp")))
> 	 (host (url-host obj))
> 	 (port (url-port-if-non-default obj))
> 	 (user (url-user obj))
> 	 (filename (car (url-path-and-query obj))))
>     (when (and (member scheme valid-schemes)
> 	       (string-match "\\`[a-zA-Z][-a-zA-Z0-9+.]*\\'" scheme)
> 	       (not (equal host "")))
>       (concat "/"
> 	      (if (not (string= scheme "file"))
> 		  (concat scheme ":"))
> 	      (if user (concat user "@"))
> 	      host
> 	      (if port (concat "#" (number-to-string port)))
> 	      ":" filename))))

This patch tries to conserve the side effect of ffap in Emacs 23. I'm
not a user of ffap, so I don't know whether it is acceptable to add such
a kludge.

> Best wishes
> Jens

Best regards, Michael.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#13961; Package emacs. (Fri, 25 Dec 2015 21:10:02 GMT) Full text and rfc822 format available.

Message #11 received at 13961 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Jens Lechtenboerger <lechten <at> wi.uni-muenster.de>, 13961 <at> debbugs.gnu.org
Subject: Re: bug#13961: 24.3; ffap-url-unwrap-remote fails for remote file URIs
Date: Fri, 25 Dec 2015 22:09:05 +0100
Michael Albinus <michael.albinus <at> gmx.de> writes:

> Tramp is bundled with Emacs 23, and it uses an extended syntax
> "/method:host:/remote/path". The "method:" part is optional; in this
> case the default method ("ssh" in your case) will be used.
>
> So it did work for you due to an unintended side effect.

Since this has been working this way for almost three years now, I think
we probably shouldn't change this back now (if I understood this thread
correctly).  So I'm closing the bug report.

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




bug closed, send any further explanations to 13961 <at> debbugs.gnu.org and Jens Lechtenboerger <lechten <at> wi.uni-muenster.de> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Fri, 25 Dec 2015 21:10:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sat, 23 Jan 2016 12:24:07 GMT) Full text and rfc822 format available.

This bug report was last modified 9 years and 151 days ago.

Previous Next


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