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

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

Re: using commit identifiers in bug reports

[Eli Zaretskii]

> From: Ivan Shmakov <ivan@siamics.net>
> Date: Sun, 18 Jan 2015 18:50:57 +0000
> Cc: 19594@debbugs.gnu.org
> 
> >>>>> 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.)

I'm sorry, but what does referring to bug numbers have to do with the
issue at hand?  All I said was that to describe the current behavior
there's no need to mention any commits, just say "as of now, Emacs
does this and that".

If you want to describe something that was caused by some specific
commit, by all means use that commit's SHA1, or any other means that
allow to easily display it.

Re: using commit identifiers in bug reports

[Ivan Shmakov]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>>> From: Ivan Shmakov  Date: Sun, 18 Jan 2015 18:50:57 +0000
>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>>> From: Ivan Shmakov  Date: Thu, 15 Jan 2015 23:47:37 +0000

[…]

 >>>> 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

	… it’s somewhat confusing…

 >> 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.)

 > I'm sorry, but what does referring to bug numbers have to do with the
 > issue at hand?  All I said was that to describe the current behavior
 > there's no need to mention any commits, just say "as of now, Emacs
 > does this and that".

	Or, in my case: “as of last week, Emacs…,” right?

 > If you want to describe something that was caused by some specific
 > commit, by all means use that commit's SHA1, or any other means that
 > allow to easily display it.

	My point is that there’s no easy way to request Git to report
	the commits (changes) made since a bug report was filed.
	/Unless/ the reporter takes care to note the particular revision
	he or she has found to be affected.  Which is the thing I do.

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

Re: using commit identifiers in bug reports

[Eli Zaretskii]

> From: Ivan Shmakov <ivan@siamics.net>
> Date: Fri, 23 Jan 2015 14:52:56 +0000
> 
>  > I'm sorry, but what does referring to bug numbers have to do with the
>  > issue at hand?  All I said was that to describe the current behavior
>  > there's no need to mention any commits, just say "as of now, Emacs
>  > does this and that".
> 
> 	Or, in my case: “as of last week, Emacs…,” right?

No, that already might be interpreted as "starting from last week".
Perhaps even my suggestion above might.  So how about "with the
current trunk, Emacs does this and that"?

> 	My point is that there’s no easy way to request Git to report
> 	the commits (changes) made since a bug report was filed.

Why do you need that?

Re: using commit identifiers in bug reports

[Dmitry Gutov]

On 01/23/2015 06:21 PM, Eli Zaretskii wrote:

>> 	Or, in my case: “as of last week, Emacs…,” right?
>
> No, that already might be interpreted as "starting from last week".
> Perhaps even my suggestion above might.  So how about "with the
> current trunk, Emacs does this and that"?

That might be a British vs American English issue.

The prevalent opinion seems to be "as of" means "at the moment of":

http://painintheenglish.com/case/4162

But some distinguish between "as of" and "as at":

http://painintheenglish.com/case/4162/#comment-22366

(whereas I don't remember seeing "as at" at all before).

Also: http://blog.harwardcommunications.com/2012/04/02/as-of/

That opinion states that the ambiguity should be resolved by the 
context. If it doesn't, I'd say the most general meaning should be 
considered (the state of affairs at that moment was...)

 >> 	My point is that there’s no easy way to request Git to report
 >> 	the commits (changes) made since a bug report was filed.
 >
 > Why do you need that?

That can be useful to the person working on that bug report.

Personally, seeing the exact hash instead of "current trunk" makes me 
more confident that the reporter indeed is using the current trunk build.

Re: using commit identifiers in bug reports

[Eli Zaretskii]

> Date: Fri, 23 Jan 2015 19:06:58 +0200
> From: Dmitry Gutov <dgutov@yandex.ru>
> CC: emacs-devel@gnu.org
> 
> On 01/23/2015 06:21 PM, Eli Zaretskii wrote:
> 
> >> 	Or, in my case: “as of last week, Emacs…,” right?
> >
> > No, that already might be interpreted as "starting from last week".
> > Perhaps even my suggestion above might.  So how about "with the
> > current trunk, Emacs does this and that"?
> 
> That might be a British vs American English issue.

I don't think so.  AFAIK, Glenn's origins are in the UK, and mine are
certainly not in the US.  And yet both of us consider that wording
awkward and somewhat confusing.

Re: using commit identifiers in bug reports

[Ivan Shmakov]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>>> Date: Fri, 23 Jan 2015 19:06:58 +0200  From: Dmitry Gutov
>>>>> On 01/23/2015 06:21 PM, Eli Zaretskii wrote:

 >>>> Or, in my case: “as of last week, Emacs…,” right?

 >>> No, that already might be interpreted as "starting from last week".
 >>> Perhaps even my suggestion above might.  So how about "with the
 >>> current trunk, Emacs does this and that"?

	I still feel it useful to include the commit identifier
	somewhere.  Why, report-emacs-bug already puts the version in
	the subject, and on Git ‘master’, a single version value may
	correspond to vastly different trees.

 >> That might be a British vs American English issue.

 > I don't think so.  AFAIK, Glenn's origins are in the UK, and mine are
 > certainly not in the US.  And yet both of us consider that wording
 > awkward and somewhat confusing.

	One more thing to note is that English Wikipedia consistently
	uses “as of” to mean “at that particular point in time” without
	any implication of the state of affairs being /changed/ at that
	same point.  See [1], for instance.

[1] https://en.wikipedia.org/wiki/Special:WhatLinksHere/Template:As_of

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

Re: using commit identifiers in bug reports

[Eli Zaretskii]

> From: Ivan Shmakov <ivan@siamics.net>
> Date: Fri, 23 Jan 2015 20:45:53 +0000
> 
> 	I still feel it useful to include the commit identifier
> 	somewhere.  Why, report-emacs-bug already puts the version in
> 	the subject, and on Git ‘master’, a single version value may
> 	correspond to vastly different trees.

report-emacs-bug is mainly for users, not for people who track the
development.  The latter are expected to try the latest master before
they report a problem.

Anyway, this is dragging for too long for such a simple issue.  Two
people independently told you that your wording looks awkward and
suggested to amend that.  Now that you understand the nature of our
confusion, it's up to you to decide what to do with that observation.

Re: using commit identifiers in bug reports

[Ivan Shmakov]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>>> From: Ivan Shmakov  Date: Fri, 23 Jan 2015 20:45:53 +0000

 >> I still feel it useful to include the commit identifier somewhere.

[…]

 > Anyway, this is dragging for too long for such a simple issue.  Two
 > people independently told you that your wording looks awkward and
 > suggested to amend that.  Now that you understand the nature of our
 > confusion, it's up to you to decide what to do with that observation.

	I didn’t mean to imply that I’m refusing to try to improve my
	wording.

	(But frankly, I’ve secretly hoped for this discussion to come to
	some CONTRIBUTE-worthy, commit identifier-friendly suggestion on
	the issue.  As it seems, the plan has failed miserably.  Alas.)

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

Re: using commit identifiers in bug reports

[Dmitry Gutov]

On 01/18/2015 08:50 PM, Ivan Shmakov wrote:
>>>>>> Eli Zaretskii <eliz@gnu.org> writes:

>   >>>> 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."

FWIW, I found that excerpt perfectly understandable. But I guess I'm not 
the target audience.

Re: using commit identifiers in bug reports

[Eli Zaretskii]

> Date: Sun, 18 Jan 2015 22:33:25 +0200
> From: Dmitry Gutov <dgutov@yandex.ru>
> 
> On 01/18/2015 08:50 PM, Ivan Shmakov wrote:
> >>>>>> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >   >>>> 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."
> 
> FWIW, I found that excerpt perfectly understandable. But I guess I'm not 
> the target audience.

Please get your attributions right: I didn't write any of that.

Re: using commit identifiers in bug reports

[Dmitry Gutov]

On 01/19/2015 05:30 AM, Eli Zaretskii wrote:

>>>    >>> 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."
>>
>> FWIW, I found that excerpt perfectly understandable. But I guess I'm not
>> the target audience.
>
> Please get your attributions right: I didn't write any of that.

Oh, sorry about that.

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