bug#19594: url-ftp: should not be aliased to url-file; url-file: use Tramp

bug#19594: url-ftp: should not be aliased to url-file; url-file: use Tramp

[Ivan Shmakov]

Package:  emacs
Severity: minor

	As of 88bc8332eb14 (2015-01-07 13:51:41 +0000), url-ftp is
	implemented as an alias to url-file, which results in the
	following (unexpected) behavior.

(let ((url-proxy-services nil))
  (url-retrieve-synchronously "ftp://localhost/dev/null"))

	Returns: a buffer.  Expected: failure, as there’s no FTP server
	running on localhost.

(let ((url-proxy-services nil))
  (url-retrieve-synchronously "file://remote.example/dev/null"))

	Results in a internal-ange-ftp-mode buffer opened.  Expected:
	the contents of the file, as retrieved via Tramp.

	I understand that FTP was once the only widespread file transfer
	protocol /and/ that ange-ftp was once the only Emacs package
	providing access to remote filesystems.  Now that Emacs has
	Tramp, I see no reason for using ange-ftp for retrieving
	resources denoted by file: scheme URIs, – unless so is the
	preference of the user.

	My suggestion would be that the FTP-specific code be split off
	url-file.el into url-ftp.el (so that ftp: URIs would exclusively
	denote resources available via FTP), /and/ new Tramp interface
	(hopefully trivial) be coded into url-file.el.

-- 
FSF associate member #7257  np. The Alchemist — Iron Maiden  … B6A0 230E 334A

bug#19594: url-ftp: should not be aliased to url-file; url-file: use Tramp

[Glenn Morris]

Ivan Shmakov wrote:

> 	As of 88bc8332eb14 (2015-01-07 13:51:41 +0000), url-ftp is
> 	implemented as an alias to url-file,

I found this confusing. You mean: "it's always been implemented as an
alias, and this remains true as of last week."
Not: "last week it was changed to be an alias."

bug#19594: url-ftp: should not be aliased to url-file; url-file: use Tramp

[Ivan Shmakov]

>>>>> Glenn Morris <rgm@gnu.org> writes:
>>>>> Ivan Shmakov wrote:

 >> As of 88bc8332eb14 (2015-01-07 13:51:41 +0000), url-ftp is
 >> implemented as an alias to url-file,

 > I found this confusing.  You mean: "it's always been implemented as an
 > alias, and this remains true as of last week."  Not: "last week it
 > was changed to be an alias."

	Actually, by using present tense, I was intending to say that
	“it was an alias for the last week’s Git checkout, and I didn’t
	bother to check when it got changed, or if it was like that
	right from the start.”

-- 
FSF associate member #7257  np. The Burning Dawn — Jami Sieber B6A0 230E 334A

bug#19594: url-ftp: should not be aliased to url-file; url-file: use Tramp

[Eli Zaretskii]

> From: Ivan Shmakov <ivan@siamics.net>
> Date: Thu, 15 Jan 2015 23:47:37 +0000
> 
> >>>>> Glenn Morris <rgm@gnu.org> writes:
> >>>>> Ivan Shmakov wrote:
> 
>  >> As of 88bc8332eb14 (2015-01-07 13:51:41 +0000), url-ftp is
>  >> implemented as an alias to url-file,
> 
>  > I found this confusing.  You mean: "it's always been implemented as an
>  > alias, and this remains true as of last week."  Not: "last week it
>  > was changed to be an alias."
> 
> 	Actually, by using present tense, I was intending to say that
> 	“it was an alias for the last week’s Git checkout, and I didn’t
> 	bother to check when it got changed, or if it was like that
> 	right from the start.”

You don't need to mention any commits or dates to convey that.  Just
state the facts.

bug#19594: using commit identifiers in bug reports

[Ivan Shmakov]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>>> From: Ivan Shmakov  Date: Thu, 15 Jan 2015 23:47:37 +0000
>>>>> Glenn Morris <rgm@gnu.org> writes:
>>>>> Ivan Shmakov wrote:

	[Moving to emacs-devel@; please drop Cc: 19594@ as irrelevant
	when replying.]

 >>>> As of 88bc8332eb14 (2015-01-07 13:51:41 +0000), url-ftp is
 >>>> implemented as an alias to url-file,

 >>> I found this confusing.  You mean: "it's always been implemented as
 >>> an alias, and this remains true as of last week."  Not: "last week
 >>> it was changed to be an alias."

 >> Actually, by using present tense, I was intending to say that “it
 >> was an alias for the last week’s Git checkout, and I didn’t bother
 >> to check when it got changed, or if it was like that right from the
 >> start.”

 > You don't need to mention any commits or dates to convey that.  Just
 > state the facts.

	While I understand that as commit identifiers are used to refer
	to both a tree state /and/ a change (diff) to said state, I find
	the ability to $ git log 88bc8332eb..HEAD -- lisp/url/url-ftp.el
	just too convenient to disregard.

	Sure, I’d be just as happy to $ git log bug:19594..HEAD, but I
	doubt that there’ll be /that/ amount of integration between Git
	and Debbugs in the foreseeable future, not to mention that I do
	not always check the reports I file against the latest master.
	(Usually, I update my Emacs working copy just a few times a
	month, and only take a brief scan over the Git developments
	between the latest update and the current master, checking for
	any /obvious/ signs that the issue was fixed in the meantime.)

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

bug#19594: url-ftp: should not be aliased to url-file; url-file: use Tramp

[Stefan Kangas]

Ivan Shmakov <ivan@siamics.net> writes:

> Package:  emacs
> Severity: minor
>
>     As of 88bc8332eb14 (2015-01-07 13:51:41 +0000), url-ftp is
>     implemented as an alias to url-file, which results in the
>     following (unexpected) behavior.
>
> (let ((url-proxy-services nil))
>   (url-retrieve-synchronously "ftp://localhost/dev/null"))
>
>     Returns: a buffer.  Expected: failure, as there’s no FTP server
>     running on localhost.
>
> (let ((url-proxy-services nil))
>   (url-retrieve-synchronously "file://remote.example/dev/null"))
>
>     Results in a internal-ange-ftp-mode buffer opened.  Expected:
>     the contents of the file, as retrieved via Tramp.
>
>     I understand that FTP was once the only widespread file transfer
>     protocol /and/ that ange-ftp was once the only Emacs package
>     providing access to remote filesystems.  Now that Emacs has
>     Tramp, I see no reason for using ange-ftp for retrieving
>     resources denoted by file: scheme URIs, – unless so is the
>     preference of the user.
>
>     My suggestion would be that the FTP-specific code be split off
>     url-file.el into url-ftp.el (so that ftp: URIs would exclusively
>     denote resources available via FTP), /and/ new Tramp interface
>     (hopefully trivial) be coded into url-file.el.

If the long-term plan now is to phase out the entire url library,
perhaps we should close this as wontfix?

Best regards,
Stefan Kangas

bug#19594: url-ftp: should not be aliased to url-file; url-file: use Tramp

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

>>     My suggestion would be that the FTP-specific code be split off
>>     url-file.el into url-ftp.el (so that ftp: URIs would exclusively
>>     denote resources available via FTP), /and/ new Tramp interface
>>     (hopefully trivial) be coded into url-file.el.
>
> If the long-term plan now is to phase out the entire url library,
> perhaps we should close this as wontfix?

I think that makes sense -- the url.el ftp: behaviour is long-standing,
and changing it this radically may break stuff.  (And the new URL
interface will handle ftp: in a manner that's more akin to what's
described here.)

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

bug#19594: url-ftp: should not be aliased to url-file; url-file: use Tramp

[Stefan Kangas]

tags 19594 + wontfix
close 19594
quit

Lars Ingebrigtsen <larsi@gnus.org> writes:
>
> Stefan Kangas <stefan@marxist.se> writes:
>
> >>     My suggestion would be that the FTP-specific code be split off
> >>     url-file.el into url-ftp.el (so that ftp: URIs would exclusively
> >>     denote resources available via FTP), /and/ new Tramp interface
> >>     (hopefully trivial) be coded into url-file.el.
> >
> > If the long-term plan now is to phase out the entire url library,
> > perhaps we should close this as wontfix?
>
> I think that makes sense -- the url.el ftp: behaviour is long-standing,
> and changing it this radically may break stuff.  (And the new URL
> interface will handle ftp: in a manner that's more akin to what's
> described here.)

Thanks; I'm therefore closing this as wontfix now.  Note that the new
URL interface is planned to be part of Emacs 28, and will cover this
use case.

Thanks for the feature suggestion.

Best regards,
Stefan Kangas