bug#17959: eww: FTP is not supported; but with ftp_proxy, it is

bug#17959: eww: FTP is not supported; but with ftp_proxy, it is

[Ivan Shmakov]

Package:  emacs
Severity: wishlist

	As of 36634f669f2c, eww unconditionally disallows browsing ftp:
	scheme URIs.  Arguably, it should only do so when no proxy
	setting is in effect for the URI in question.

	For instance, with ("ftp" . "MYPROXY:PORT") in
	url-proxy-services (and user-error commented out in eww.el)
	M-x eww shows FTP sites perfectly fine.  Consider, e. g.:

M-x eww RET ftp://ladsftp.nascom.nasa.gov/

You are user #109 of 800 simultaneous users allowed.

…
[DIR]
subsets. . . . . . . . . . . . . Dec 31  1969
────────────────────────────────────────────────────────────────────────
Generated Sun, 06 Jul 2014 19:12:54 GMT by MYPROXY
(squid/3.1.6)

-- 
FSF associate member #7257	http://boycottsystemd.org/

bug#17959: eww: FTP is not supported; but with ftp_proxy, it is

[Ted Zlatanov]

On Sun, 06 Jul 2014 19:15:46 +0000 Ivan Shmakov <ivan@siamics.net> wrote: 

IS> Package:  emacs
IS> Severity: wishlist

IS> 	As of 36634f669f2c, eww unconditionally disallows browsing ftp:
IS> 	scheme URIs.  Arguably, it should only do so when no proxy
IS> 	setting is in effect for the URI in question.

IS> 	For instance, with ("ftp" . "MYPROXY:PORT") in
IS> 	url-proxy-services (and user-error commented out in eww.el)
IS> 	M-x eww shows FTP sites perfectly fine.  Consider, e. g.:

IS> M-x eww RET ftp://ladsftp.nascom.nasa.gov/

IS> You are user #109 of 800 simultaneous users allowed.

What would be the upside of simply allowing browsing ftp: scheme?

If it only works with the proxy services you note, it seems like a
pretty rare use case.

Ted

bug#17959: eww: FTP is not supported; but with ftp_proxy, it is

[Lars Magne Ingebrigtsen]

Ivan Shmakov <ivan@siamics.net> writes:

> Package:  emacs
> Severity: wishlist
>
> 	As of 36634f669f2c, eww unconditionally disallows browsing ftp:
> 	scheme URIs.  Arguably, it should only do so when no proxy
> 	setting is in effect for the URI in question.
>
> 	For instance, with ("ftp" . "MYPROXY:PORT") in
> 	url-proxy-services (and user-error commented out in eww.el)
> 	M-x eww shows FTP sites perfectly fine.  Consider, e. g.:
>
> M-x eww RET ftp://ladsftp.nascom.nasa.gov/

Is there any point in using eww for ftp?  It seems like a duplication of
functionality.  The Emacs ftp browser is fine, I think.

So I'm closing this.

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

bug#17959: eww: FTP is not supported; but with ftp_proxy, it is

[Ivan Shmakov]

reopen 17959
thanks

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>>>>> Ivan Shmakov <ivan@siamics.net> writes:

 >> Package: emacs Severity: wishlist

 >> As of 36634f669f2c, eww unconditionally disallows browsing ftp:
 >> scheme URIs.  Arguably, it should only do so when no proxy setting
 >> is in effect for the URI in question.

 >> For instance, with ("ftp" . "MYPROXY:PORT") in url-proxy-services
 >> (and user-error commented out in eww.el) M-x eww shows FTP sites
 >> perfectly fine.  Consider, e. g.:

 >> M-x eww RET ftp://ladsftp.nascom.nasa.gov/

 > Is there any point in using eww for ftp?  It seems like a duplication
 > of functionality.  The Emacs ftp browser is fine, I think.

	… Except that it doesn’t support using an HTTP proxy to access
	FTP servers, either, and I’ve seen networks where it’s the only
	option.  (Due to firewall settings, NAT, etc.)

	Given that the only thing that EWW has to do to support
	ftp_proxy is to ensure the user configuration specifies an HTTP
	proxy to use for the target ftp: URI, it just seems like to
	simple a feature to omit it.

	When no HTTP proxy is specified for the URI, EWW should indeed
	somehow invoke the Emacs native FTP client instead.

	I guess the same approach may be applied to the other URI
	schemes just as well (gopher:, perhaps?)

 > So I'm closing this.

	I have no objections to classifying this as ‘wontfix’, but I’d
	rather keep this opened for the issue to remain visible to the
	community.  (FWIW, http://debbugs.gnu.org/ hides closed issues
	by default.)

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

bug#17959: eww: FTP is not supported; but with ftp_proxy, it is

[Lars Magne Ingebrigtsen]

Ivan Shmakov <ivan@siamics.net> writes:

>  > So I'm closing this.
>
> 	I have no objections to classifying this as ‘wontfix’, but I’d
> 	rather keep this opened for the issue to remain visible to the
> 	community.  (FWIW, http://debbugs.gnu.org/ hides closed issues
> 	by default.)

That's the point of closing bugs reports -- so that other maintainers
don't have to bother with them.  Closing again.

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

debbugs.gnu.org: is it user-centric or developer-centric?

[Ivan Shmakov]

	Could someone please clarify on the proper usage of
	debbugs.gnu.org?  Specifically, per my prior experience with the
	Debian BTS, the issues which the developers do not consider
	worth fixing, but which are otherwise valid, are tagged
	‘wontfix’, but /not/ closed.

	The rationale behind that is that the issues both remain visible
	to the /users/ of the package, /and/ are known to be “dealt
	with” (in a way) to the developers.

	Recently, two of my bug reports filed against Emacs (#17959 and
	#19109, specifically) were closed without the issues being
	actually fixed.  This makes them eligible for archiving, which
	will hide them from the (default) BTS view.

	Granted, Debian BTS was established to serve /both/ the
	developers /and/ the users of the package (or at least it’s my
	reading of the Debian Social Contract.)  I thus wonder if my
	experience is applicable to the Debbugs instance run by the GNU
	project; or if that instance is instead targeted primarily at
	developers, and thus merely sharing the knowledge of the
	existing issues (including those arising from some “singular
	usage pattern”, so to say) among the users is out of its scope?

	TIA.

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>>>>> Ivan Shmakov <ivan@siamics.net> writes:
>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

 >>> So I'm closing this.

 >> I have no objections to classifying this as ‘wontfix’, but I’d
 >> rather keep this opened for the issue to remain visible to the
 >> community.  (FWIW, http://debbugs.gnu.org/ hides closed issues by
 >> default.)

	I stand corrected: merely closing the bug doesn’t hide it from
	the public view.  However, it makes the bug eligible for
	archiving, and the archived bugs /do/ get hidden by default.

 > That's the point of closing bugs reports -- so that other maintainers
 > don't have to bother with them.

	Wouldn’t ‘wontfix’ be enough for that?

 > Closing again.

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

Re: debbugs.gnu.org: is it user-centric or developer-centric?

[Glenn Morris]

Ivan Shmakov wrote:

> 	debbugs.gnu.org? Specifically, per my prior experience with the
> 	Debian BTS, the issues which the developers do not consider
> 	worth fixing, but which are otherwise valid, are tagged
> 	'wontfix', but /not/ closed.

https://lists.debian.org/debian-devel/2014/11/msg00779.html

    [...] if the bug isn't open to discussion, I close it. I think
    that's fairly common across Debian. If it's tagged wontfix but still
    open, that generally means one of two things: either it's still open
    for discussion, but the maintainers are indicating their current
    thinking on it, or it's a commonly-reported false positive (from the
    maintainer's perspective) and they're leaving it open so that people
    will see it in the bug list and see that someone else already
    reported it.

Seems like a good summary to me.

We have 1000s of bugs. Closing ones that are never going to go anywhere
is essential.

Re: debbugs.gnu.org: is it user-centric or developer-centric?

[Ivan Shmakov]

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

 >> Specifically, per my prior experience with the Debian BTS, the
 >> issues which the developers do not consider worth fixing, but which
 >> are otherwise valid, are tagged 'wontfix', but /not/ closed.

 > https://lists.debian.org/debian-devel/2014/11/msg00779.html

 > [...] if the bug isn't open to discussion, I close it.  I think
 > that's fairly common across Debian.  If it's tagged wontfix but still
 > open, that generally means one of two things: either it's still open
 > for discussion, but the maintainers are indicating their current
 > thinking on it, or it's a commonly-reported false positive (from the
 > maintainer's perspective) and they're leaving it open so that people
 > will see it in the bug list and see that someone else already
 > reported it.

 > Seems like a good summary to me.

	I do not seem to understand the “isn’t open to discussion” part.
	Is it something along the lines of “I have decided, and my
	decision is final”?

 > We have 1000s of bugs.  Closing ones that are never going to go
 > anywhere is essential.

	FWIW, #19109 already provides a trivial workaround for the
	issue, and I could just as well add one I personally use to
	#17959.  My primary concern is that following the closure, the
	bugs will become less visible, making it more difficult for the
	users having preferences similar to mine to find these
	workarounds.

	My intent is to devise a proper fix for #17959 eventually.
	As for #19109, we seem to have a fundamental disagreement on
	whether Emacs should or should not be allowed to pop a buffer at
	some random time, possibly interfering with whatever the user
	does at the moment.

-- 
FSF associate member #7257  np. Mourning Star — Kamelot … 3013 B6A0 230E 334A

bug#17959: support accessing FTP services via HTTP proxies

[Ivan Shmakov]

[-- Attachment #1: Type: text/plain, Size: 794 bytes --]

>>>>> Ivan Shmakov <ivan@siamics.net> writes:

[…]

 > Given that the only thing that EWW has to do to support ftp_proxy is
 > to ensure the user configuration specifies an HTTP proxy to use for
 > the target ftp: URI, it just seems like to simple a feature to omit
 > it.

	The patch MIMEd seems to resolve the issue.

 > When no HTTP proxy is specified for the URI, EWW should indeed
 > somehow invoke the Emacs native FTP client instead.

 > I guess the same approach may be applied to the other URI schemes
 > just as well (gopher:, perhaps?)

	FTR, – I’ve tried to access [1] via Squid, and it just worked.

[1] gopher://gopher.docfile.org/1/world/monitoring/uptime

[…]

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

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/diff, Size: 817 bytes --]

--- a/lisp/net/eww.el	2014-12-09 03:21:57 +0000
+++ b/lisp/net/eww.el	2014-12-16 19:59:32 +0000
@@ -252,8 +238,15 @@
   (setq url (string-trim url))
   (cond ((string-match-p "\\`file:/" url))
 	;; Don't mangle file: URLs at all.
-        ((string-match-p "\\`ftp://" url)
-         (user-error "FTP is not supported."))
+	((let* ((parsed (url-generic-parse-url url))
+		(loader (url-scheme-get-property (url-type parsed) 'loader))
+		(proxy  (and (url-host parsed)
+			     (url-find-proxy-for-url
+			      parsed (url-host parsed)))))
+	   (and (eq 'url-ftp loader)
+		(or (not proxy)
+		    (not (string-match-p "^https?://" proxy)))))
+	 (user-error "Direct FTP is not supported."))
         (t
          (if (and (= (length (split-string url)) 1)
 		  (or (and (not (string-match-p "\\`[\"\'].*[\"\']\\'" url))

bug#17959: support accessing FTP services via HTTP proxies

[Ivan Shmakov]

	Alternatively, one may question of why the guard was necessary
	in the code in the first place?

	Scanning through the url*.el code, I’ve found that there’re
	certain differences in handling URIs.  Namely, while some URI
	scheme handlers (like http:) retrieve a document when a URI is
	referenced, others (like irc:) instead call some “third-party”
	code, and there’s also a group (news:, file:, ftp:) of handlers
	which follow either of these ways depending on specific
	conditions.

	And in the case of FTP, – the condition upon which no document
	is retrieved is: the URI in question refers to a directory.

	The differences are due to the fact that while some URIs (say,
	news:877fxricgb.fsf_-_@violet.siamics.net or
	http://example.com/) refer to certain /documents,/ there’re also
	URIs which are unlikely to ever denote anything like that (think
	of, say, geo:20,15.)

	Thus, my suggestion would be to:

	• allow the caller of the url*.el facilities to explicitly state
	  whether it’s interested in a document to be returned, in some
	  code to be called, or either;

	• in the ‘url-file’ function, – return a document of some form
	  (possibly the unprocessed output of the respective FTP
	  command) when given a URI which refers to a directory, – if so
	  is the preference of the caller;

	• (not directly related to this bug) adjust ‘url-news’ (and
	  possibly others) behavior similarly, perhaps going as far as
	  allowing the caller to specify its preferences regarding the
	  representation for such a document, – in the spirit of the
	  HTTP Accept: header.

	I guess all of the above warrant separate bug reports, which I
	hope to file shortly.

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

bug#19822: url-retrieve: allow to fail when no document is associated with the URI

[Ivan Shmakov]

Package:  emacs
Severity: wishlist

	The handling of the news: (nntp:), irc:, and (as it seems) ftp:
	(file:) URI schemes is implemented in such a way that a
	/successful/ url-retrieve call is /not/ in fact guaranteed to
	return a “retrieved document” of any kind.  Consider, e. g.:

(let ((url-proxy-services nil))
  (list (url-retrieve "news://news.aioe.org/alt.sources"
                      (lambda (&rest any) (message "news: %S" any)))
        (url-retrieve "irc://irc.freenode.net:6667/x-test-channel"
                      (lambda (&rest any) (message "irc:  %S" any)))))

	Here, the first call starts up Gnus and opens a *Summary* buffer
	for the group; the second starts Rcirc by default; either call
	returns nil.

	I’d expect for these two calls to instead produce the buffers
	/describing/ those respective resources – the newsgroup (say,
	its XOVER data) and the IRC channel (the server responses to a
	few IRC commands issued for the channel.)  That is: I’d expect
	url-retrieve to behave much like wget(1), – /not/ like, say,
	run-mailcap(1).

	Naturally, this is orthogonal to the use of Gnus, Rcirc, etc. to
	do the actual job; and also to the ability to spawn them via
	M-x browse-url.  (Which seems unsupported, anyway.)

	As for the possible implementation, there may be a separate
	dynamic variable (say, url-retrieve-action) to tell the scheme
	handlers whether they should only try to retrieve the URI (and
	signal an error if not supported), or that they /may/ resort to
	the current behavior (i. e., start up some scheme-specific
	interaction facility.)

	Alternatively, url-retrieve may be changed to pass an additional
	non-nil argument to the scheme handler function in the case that
	the call is not intended to result in further user interaction.
	There may be either a separate call (url-run?) to request such
	an interaction, or a new argument to url-retrieve.

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

Re: bug#19822: url-retrieve: allow to fail when no document is associated with the URI

[Lars Ingebrigtsen]

Ivan Shmakov <ivan@siamics.net> writes:

> The handling of the news: (nntp:), irc:, and (as it seems) ftp:
> (file:) URI schemes is implemented in such a way that a
> /successful/ url-retrieve call is /not/ in fact guaranteed to
> return a “retrieved document” of any kind.  Consider, e. g.:
>
> (let ((url-proxy-services nil))
> (list (url-retrieve "news://news.aioe.org/alt.sources"
> (lambda (&rest any) (message "news: %S" any)))
> (url-retrieve "irc://irc.freenode.net:6667/x-test-channel"
> (lambda (&rest any) (message "irc:  %S" any)))))
>
> Here, the first call starts up Gnus and opens a *Summary* buffer
> for the group; the second starts Rcirc by default; either call
> returns nil.

I think all these non-http{s,} things in the URL library should be
marked obsolete and removed.  There is very little utility to them (some
have been broken for years without anybody noticing), and they are very
fiddly to maintain.

Anybody mind if I remove them for Emacs 25.2?

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

bug#19822: url-retrieve: allow to fail when no document is associated with the URI

[Drew Adams]

> I think all these non-http{s,} things in the URL library should be
> marked obsolete and removed.  There is very little utility to them (some
> have been broken for years without anybody noticing), and they are very
> fiddly to maintain.
> 
> Anybody mind if I remove them for Emacs 25.2?

1. Such a proposal should explicitly list each of the "things" you
   propose to mark as obsolete.

2. Marking something as obsolete (deprecating it) does not imply
   that you can remove it.  Normally (although I do know that Emacs
   is not necessarily normal) deprecated "things" remain, and remain
   supported for quite some time before they are desupported.  And
   that means that their supporting code remains (is not removed).

   Or did you perhaps mean remove only from "the URL library",
   and not remove from Emacs?

(All of this said, I probably do not care, personally, what you
do with the unspecified "non-http{s,} things in the URL library"
that you want to remove.)

RE: bug#19822: url-retrieve: allow to fail when no document is associated with the URI

[Drew Adams]

> I think all these non-http{s,} things in the URL library should be
> marked obsolete and removed.  There is very little utility to them (some
> have been broken for years without anybody noticing), and they are very
> fiddly to maintain.
> 
> Anybody mind if I remove them for Emacs 25.2?

1. Such a proposal should explicitly list each of the "things" you
   propose to mark as obsolete.

2. Marking something as obsolete (deprecating it) does not imply
   that you can remove it.  Normally (although I do know that Emacs
   is not necessarily normal) deprecated "things" remain, and remain
   supported for quite some time before they are desupported.  And
   that means that their supporting code remains (is not removed).

   Or did you perhaps mean remove only from "the URL library",
   and not remove from Emacs?

(All of this said, I probably do not care, personally, what you
do with the unspecified "non-http{s,} things in the URL library"
that you want to remove.)

bug#19822: url-retrieve: allow to fail when no document is associated with the URI

[Lars Ingebrigtsen]

Ivan Shmakov <ivan@siamics.net> writes:

> The handling of the news: (nntp:), irc:, and (as it seems) ftp:
> (file:) URI schemes is implemented in such a way that a
> /successful/ url-retrieve call is /not/ in fact guaranteed to
> return a “retrieved document” of any kind.  Consider, e. g.:
>
> (let ((url-proxy-services nil))
> (list (url-retrieve "news://news.aioe.org/alt.sources"
> (lambda (&rest any) (message "news: %S" any)))
> (url-retrieve "irc://irc.freenode.net:6667/x-test-channel"
> (lambda (&rest any) (message "irc:  %S" any)))))
>
> Here, the first call starts up Gnus and opens a *Summary* buffer
> for the group; the second starts Rcirc by default; either call
> returns nil.

I think all these non-http{s,} things in the URL library should be
marked obsolete and removed.  There is very little utility to them (some
have been broken for years without anybody noticing), and they are very
fiddly to maintain.

Anybody mind if I remove them for Emacs 25.2?

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

Re: bug#19822: url-retrieve: allow to fail when no document is associated with the URI

[Ted Zlatanov]

On Fri, 25 Dec 2015 20:00:34 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> I think all these non-http{s,} things in the URL library should be
LI> marked obsolete and removed.  There is very little utility to them (some
LI> have been broken for years without anybody noticing), and they are very
LI> fiddly to maintain.

LI> Anybody mind if I remove them for Emacs 25.2?

I'd leave at least the ftp and file protocols.

Ted

bug#19822: url-retrieve: allow to fail when no document is associated with the URI

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I'd leave at least the ftp and file protocols.

Mm, yes.  But the rest could be retired, I think.

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

Re: bug#19822: url-retrieve: allow to fail when no document is associated with the URI

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I'd leave at least the ftp and file protocols.

Mm, yes.  But the rest could be retired, I think.

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

bug#19822: url-retrieve: allow to fail when no document is associated with the URI

[Ted Zlatanov]

On Fri, 25 Dec 2015 20:00:34 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> I think all these non-http{s,} things in the URL library should be
LI> marked obsolete and removed.  There is very little utility to them (some
LI> have been broken for years without anybody noticing), and they are very
LI> fiddly to maintain.

LI> Anybody mind if I remove them for Emacs 25.2?

I'd leave at least the ftp and file protocols.

Ted

bug#19822: url-retrieve: allow to fail when no document is associated with the URI

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Ivan Shmakov <ivan@siamics.net> writes:
>
>> The handling of the news: (nntp:), irc:, and (as it seems) ftp:
>> (file:) URI schemes is implemented in such a way that a
>> /successful/ url-retrieve call is /not/ in fact guaranteed to
>> return a “retrieved document” of any kind.  Consider, e. g.:
>>
>> (let ((url-proxy-services nil))
>> (list (url-retrieve "news://news.aioe.org/alt.sources"
>> (lambda (&rest any) (message "news: %S" any)))
>> (url-retrieve "irc://irc.freenode.net:6667/x-test-channel"
>> (lambda (&rest any) (message "irc:  %S" any)))))
>>
>> Here, the first call starts up Gnus and opens a *Summary* buffer
>> for the group; the second starts Rcirc by default; either call
>> returns nil.
>
> I think all these non-http{s,} things in the URL library should be
> marked obsolete and removed.  There is very little utility to them (some
> have been broken for years without anybody noticing), and they are very
> fiddly to maintain.
>
> Anybody mind if I remove them for Emacs 25.2?

Hi Lars,

This is a good idea, but it seems like it was never done?  There was
no one protesting the proposal at the time (December 2015).  Perhaps
we should move some of them to obsolete/ before Emacs 27.1?

Best regards,
Stefan Kangas

bug#19822: url-retrieve: allow to fail when no document is associated with the URI

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> This is a good idea, but it seems like it was never done?  There was
> no one protesting the proposal at the time (December 2015).  Perhaps
> we should move some of them to obsolete/ before Emacs 27.1?

I think that would be good, but Eli should probably weigh in here.

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

bug#19822: url-retrieve: allow to fail when no document is associated with the URI

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Mon, 30 Sep 2019 07:47:43 +0200
> Cc: 19822@debbugs.gnu.org, Ivan Shmakov <ivan@siamics.net>
> 
> Stefan Kangas <stefan@marxist.se> writes:
> 
> > This is a good idea, but it seems like it was never done?  There was
> > no one protesting the proposal at the time (December 2015).  Perhaps
> > we should move some of them to obsolete/ before Emacs 27.1?
> 
> I think that would be good, but Eli should probably weigh in here.

I'm not sure I understand the proposal: we are being asked to remove
ftp:, news:, etc. from being supported by the URL library?  I think
those protocols are still widely used, no?

bug#19822: url-retrieve: allow to fail when no document is associated with the URI

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I'm not sure I understand the proposal: we are being asked to remove
> ftp:, news:, etc. from being supported by the URL library?  I think
> those protocols are still widely used, no?

Not ftp:, but news: and gopher: and the other obscure ones.

They aren't used a lot and some of them do not work at all currently.

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

bug#19822: url-retrieve: allow to fail when no document is associated with the URI

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: stefan@marxist.se,  19822@debbugs.gnu.org,  ivan@siamics.net
> Date: Mon, 30 Sep 2019 09:30:36 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I'm not sure I understand the proposal: we are being asked to remove
> > ftp:, news:, etc. from being supported by the URL library?  I think
> > those protocols are still widely used, no?
> 
> Not ftp:, but news: and gopher: and the other obscure ones.
> 
> They aren't used a lot and some of them do not work at all currently.

How are network news URL referenced, if not by 'news:'?

Anyway, can we please have an explicit list of those we'd like to
deprecate, and some usage numbers to back that?  I'd like to have some
more firm basis for this decision, if possible.

Thanks.

bug#19822: url-retrieve: allow to fail when no document is associated with the URI

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> How are network news URL referenced, if not by 'news:'?

They aren't, really.  You use a newsreader to read news -- no modern
browser supports news: URLs.

> Anyway, can we please have an explicit list of those we'd like to
> deprecate, and some usage numbers to back that?  I'd like to have some
> more firm basis for this decision, if possible.

Geez.  Gathering the list of schemes supported is more work than I
thought, because it's not an explicit list.

Here's the schemes it supports:

imap:
file:
http:
https:
ldap:
mail:
mailto:
man:
info:
data:
news:
snews:
nfs:
ftp:
rlogin:
telnet:
tn3270:


Of these, file:, http:, https:, data: and ftp: are the only ones that
are useful.

But on consideration, perhaps it's just best to leave them all as they
are to smoulder.  As you may remember, there's a with-fetched-url branch
that reimplements the entire URL interface, and it only supports the
modern schemes.  (I'm planning on merging when master goes to Emacs 28.)

So we can leave the url.el interfaces alone as a backwards-compatible
stuff and then pension off the entire url.el machinery in, say, Emacs 34.

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

bug#19822: url-retrieve: allow to fail when no document is associated with the URI

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: stefan@marxist.se,  19822@debbugs.gnu.org,  ivan@siamics.net
> Date: Mon, 30 Sep 2019 16:40:02 +0200
> 
> But on consideration, perhaps it's just best to leave them all as they
> are to smoulder.  As you may remember, there's a with-fetched-url branch
> that reimplements the entire URL interface, and it only supports the
> modern schemes.  (I'm planning on merging when master goes to Emacs 28.)
> 
> So we can leave the url.el interfaces alone as a backwards-compatible
> stuff and then pension off the entire url.el machinery in, say, Emacs 34.

Fine with me, thanks.

bug#19822: url-retrieve: allow to fail when no document is associated with the URI

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Of these, file:, http:, https:, data: and ftp: are the only ones that
> are useful.
>
> But on consideration, perhaps it's just best to leave them all as they
> are to smoulder.  As you may remember, there's a with-fetched-url branch
> that reimplements the entire URL interface, and it only supports the
> modern schemes.  (I'm planning on merging when master goes to Emacs 28.)
>
> So we can leave the url.el interfaces alone as a backwards-compatible
> stuff and then pension off the entire url.el machinery in, say, Emacs 34.

I don't feel very strongly about this, but I'm curious: Why don't you
want to obsolete at least some of them?  I think they add user
confusion and are just not very helpful.

Personally, I wouldn't mind a middle ground here: to only obsolete the
very low hanging fruit.  To be more concrete, it doesn't seem to me
that it would take much effort to immediately obsolete url-irc.el,
url-news.el, url-imap.el and url-ns.el.

I could volunteer to cook up a patch if that's indeed something we
want to do.  Otherwise, I suggest to close this bug report as wontfix.

Best regards,
Stefan Kangas

bug#19822: url-retrieve: allow to fail when no document is associated with the URI

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Tue, 1 Oct 2019 15:19:28 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, 19822@debbugs.gnu.org, Ivan Shmakov <ivan@siamics.net>
> 
> > So we can leave the url.el interfaces alone as a backwards-compatible
> > stuff and then pension off the entire url.el machinery in, say, Emacs 34.
> 
> I don't feel very strongly about this, but I'm curious: Why don't you
> want to obsolete at least some of them?  I think they add user
> confusion and are just not very helpful.

How would obsoleting them help avoid that confusion?

bug#19822: url-retrieve: allow to fail when no document is associated with the URI

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> > I don't feel very strongly about this, but I'm curious: Why don't you
> > want to obsolete at least some of them?  I think they add user
> > confusion and are just not very helpful.
>
> How would obsoleting them help avoid that confusion?

I think in at least two ways:

1. Obsoleting is a fairly strong sign that this is code that it's
probably better to avoid.

2. AFAIU, the point of obsoleting a file is to eventually remove it.
If it doesn't exist, it can't confuse anyone.

Best regards,
Stefan Kangas

bug#19822: url-retrieve: allow to fail when no document is associated with the URI

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Tue, 1 Oct 2019 15:44:15 +0200
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 19822@debbugs.gnu.org, Ivan Shmakov <ivan@siamics.net>
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > > I don't feel very strongly about this, but I'm curious: Why don't you
> > > want to obsolete at least some of them?  I think they add user
> > > confusion and are just not very helpful.
> >
> > How would obsoleting them help avoid that confusion?
> 
> I think in at least two ways:
> 
> 1. Obsoleting is a fairly strong sign that this is code that it's
> probably better to avoid.
> 
> 2. AFAIU, the point of obsoleting a file is to eventually remove it.
> If it doesn't exist, it can't confuse anyone.

I understand how removing will end the confusion.  What I don't quite
understand is how obsoleting will help avoiding the confusion.  I
think the obsolete messages just add to the confusion, not take away.

Lars suggested to let this stuff become fallback, which means users
will see the confusing stuff much less frequently.  That made sense to
me.

bug#19822: url-retrieve: allow to fail when no document is associated with the URI

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> I understand how removing will end the confusion.  What I don't quite
> understand is how obsoleting will help avoiding the confusion.  I
> think the obsolete messages just add to the confusion, not take away.

I see your point.

> Lars suggested to let this stuff become fallback, which means users
> will see the confusing stuff much less frequently.  That made sense to
> me.

Yes, I agree.

However, I did provide a patch to obsolete the Netscape code, as a
special case.  Please let me know if that patch should be installed or
not -- either way is fine with me.

Once we have a decision on that, I think we should close this
particular bug as wontfix.  Perhaps we should also look over to see if
there are any other bug reports which deserve closing too, since any
efforts are probably better spent improving the with-fetched-url
branch.

Best regards,
Stefan Kangas

bug#19822: url-retrieve: allow to fail when no document is associated with the URI

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Tue, 1 Oct 2019 17:13:34 +0200
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 19822@debbugs.gnu.org, Ivan Shmakov <ivan@siamics.net>
> 
> However, I did provide a patch to obsolete the Netscape code, as a
> special case.  Please let me know if that patch should be installed or
> not -- either way is fine with me.

I'll let Lars decide.

Thanks.

bug#19822: url-retrieve: allow to fail when no document is associated with the URI

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> I don't feel very strongly about this, but I'm curious: Why don't you
> want to obsolete at least some of them?  I think they add user
> confusion and are just not very helpful.

I think an across-the-board obsoletion is easier to communicate than
doing it piece by piece.

But I don't feel very strongly about this, either.

> Personally, I wouldn't mind a middle ground here: to only obsolete the
> very low hanging fruit.  To be more concrete, it doesn't seem to me
> that it would take much effort to immediately obsolete url-irc.el,
> url-news.el, url-imap.el and url-ns.el.

Oh, I missed irc: and ns:.  :-/  Yes, those are pretty useless...

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

bug#19822: url-retrieve: allow to fail when no document is associated with the URI

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> > I don't feel very strongly about this, but I'm curious: Why don't you
> > want to obsolete at least some of them?  I think they add user
> > confusion and are just not very helpful.
>
> I think an across-the-board obsoletion is easier to communicate than
> doing it piece by piece.

Good point, thanks.

> > Personally, I wouldn't mind a middle ground here: to only obsolete the
> > very low hanging fruit.  To be more concrete, it doesn't seem to me
> > that it would take much effort to immediately obsolete url-irc.el,
> > url-news.el, url-imap.el and url-ns.el.
>
> Oh, I missed irc: and ns:.  :-/  Yes, those are pretty useless...

Given the above, how about just obsoleting url-ns.el?  This file
handles Netscape configuration files, and there should be no problem
communicating the irrelevancy of that.

Best regards,
Stefan Kangas

bug#19822: url-retrieve: allow to fail when no document is associated with the URI

[Stefan Kangas]

[-- Attachment #1: Type: text/plain, Size: 268 bytes --]

Stefan Kangas <stefan@marxist.se> writes:

> Given the above, how about just obsoleting url-ns.el?  This file
> handles Netscape configuration files, and there should be no problem
> communicating the irrelevancy of that.

Patch attached.

Best regards,
Stefan Kangas

[-- Attachment #2: 0001-Move-url-ns.el-to-obsolete.patch --]
[-- Type: application/octet-stream, Size: 1734 bytes --]

From 6a5d417f6895abcbf61b8626ba577b06ba02cb8b Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefankangas@gmail.com>
Date: Tue, 1 Oct 2019 16:20:02 +0200
Subject: [PATCH] Move url-ns.el to obsolete/

* lisp/url/url-ns.el: Move from here...
* lisp/obsolete/url-ns.el: ...to here.  (Bug#19822)
---
 etc/NEWS                         | 5 +++++
 lisp/{url => obsolete}/url-ns.el | 6 ++++++
 2 files changed, 11 insertions(+)
 rename lisp/{url => obsolete}/url-ns.el (96%)

diff --git a/etc/NEWS b/etc/NEWS
index 9a9e25bea9..cf4a440da6 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -2679,6 +2679,11 @@ directories if you ask it for a "file:///dir" URL.  Since this is a
 low-level library, such decisions (if they are to be made at all) are
 left to higher-level functions.
 
+---
+** The url-ns.el library is now marked obsolete.
+This library is used to open configuration files for the long defunct
+web browser Netscape, and is no longer relevant.
+
 ** Image mode
 
 *** New library Exif.
diff --git a/lisp/url/url-ns.el b/lisp/obsolete/url-ns.el
similarity index 96%
rename from lisp/url/url-ns.el
rename to lisp/obsolete/url-ns.el
index 733f3a9e47..a301e461ad 100644
--- a/lisp/url/url-ns.el
+++ b/lisp/obsolete/url-ns.el
@@ -3,6 +3,7 @@
 ;; Copyright (C) 1997-1999, 2004-2019 Free Software Foundation, Inc.
 
 ;; Keywords: comm, data, processes, hypermedia
+;; Obsolete-since: 27.1
 
 ;; This file is part of GNU Emacs.
 
@@ -19,6 +20,11 @@
 ;; You should have received a copy of the GNU General Public License
 ;; along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.
 
+;;; Commentary:
+
+;; This file is obsolete.  For more information, see:
+;; https://debbugs.gnu.org/19822
+
 ;;; Code:
 
 (require 'url-gw)
-- 
2.23.0

bug#19822: url-retrieve: allow to fail when no document is associated with the URI

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> +** The url-ns.el library is now marked obsolete.
> +This library is used to open configuration files for the long defunct
> +web browser Netscape, and is no longer relevant.

Looks good to me.

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

bug#19822: url-retrieve: allow to fail when no document is associated with the URI

[Stefan Kangas]

tags 19822 + wontfix
close 19822
thanks

Lars Ingebrigtsen <larsi@gnus.org> writes:

> > +** The url-ns.el library is now marked obsolete.
> > +This library is used to open configuration files for the long defunct
> > +web browser Netscape, and is no longer relevant.
>
> Looks good to me.

Thanks, now pushed to master as commit 41f59e71e2.

I'm also closing this bug as wontfix, since the consensus seems to be
that it's not worth making any changes here at this point.

Best regards,
Stefan Kangas

bug#17959: support accessing FTP services via HTTP proxies

[Ivan Shmakov]

>>>>> Ivan Shmakov <ivan@siamics.net> writes:

[…]

 > Thus, my suggestion would be to:

 > • allow the caller of the url*.el facilities to explicitly state
 > whether it’s interested in a document to be returned, in some code to
 > be called, or either;

[…]

 > I guess all of the above warrant separate bug reports, which I
 > hope to file shortly.

	Filed #19822 for the first point.  Once it’s decided how to fix
	that (and if), changes for url-file, url-irc, url-news, etc.,
	wouldn’t be all that a big deal.

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