GNU bug report logs - #58049
29.0.50; Obsolete url schemes "info" and "man"

Previous Next

Package: emacs;

Reported by: Stefan Kangas <stefankangas <at> gmail.com>

Date: Sat, 24 Sep 2022 23:06:01 UTC

Severity: wishlist

Found in version 29.0.50

Done: Stefan Kangas <stefankangas <at> gmail.com>

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 58049 in the body.
You can then email your comments to 58049 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#58049; Package emacs. (Sat, 24 Sep 2022 23:06:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Stefan Kangas <stefankangas <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sat, 24 Sep 2022 23:06:01 GMT) Full text and rfc822 format available.

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; Obsolete url schemes "info" and "man"
Date: Sat, 24 Sep 2022 19:05:13 -0400
Severity: wishlist

I don't think non-standard URLs like these are used much, and they're
probably not very useful.  They're more likely to cause confusion.

    (url-retrieve-synchronously "info:url#Retrieving URLs")
    (url-retrieve-synchronously "man:cat")

I suggest support for such URLs is obsoleted, and that they are removed
from (info "(url) Supported URL Types").


In GNU Emacs 29.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version
 3.24.24, cairo version 1.16.0) of 2022-09-24 built on joffe
Repository revision: 351d4dce21eaad30bb8b8a7d6a64463164f3e0bc
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Debian GNU/Linux 11 (bullseye)

Configured using:
 'configure --with-native-compilation'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES
NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3
THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB

Important settings:
  value of $LC_COLLATE: C
  value of $LC_CTYPE: sv_SE.UTF-8
  value of $LC_TIME: C
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort hashcash mail-extr emacsbug message mailcap yank-media puny
dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg
rfc6068 epg-config gnus-util text-property-search time-date mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
cl-loaddefs comp comp-cstr warnings icons subr-x rx cl-seq cl-macs gv
cl-extra help-mode bytecomp byte-compile cconv cl-lib sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils rmc iso-transl tooltip
eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd
fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
faces cus-face macroexp files window text-properties overlay sha1 md5
base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit xinput2 x multi-tty make-network-process
native-compile emacs)

Memory information:
((conses 16 76956 6382)
 (symbols 48 7158 0)
 (strings 32 19911 1851)
 (string-bytes 1 602537)
 (vectors 16 15964)
 (vector-slots 8 323593 16028)
 (floats 8 42 26)
 (intervals 56 235 0)
 (buffers 1000 12))




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58049; Package emacs. (Sun, 25 Sep 2022 04:59:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 58049 <at> debbugs.gnu.org
Subject: Re: bug#58049: 29.0.50; Obsolete url schemes "info" and "man"
Date: Sun, 25 Sep 2022 07:57:46 +0300
> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Sat, 24 Sep 2022 19:05:13 -0400
> 
> Severity: wishlist
> 
> I don't think non-standard URLs like these are used much, and they're
> probably not very useful.  They're more likely to cause confusion.

How do you know all these things?  Do you have any data to support
those opinions?

>     (url-retrieve-synchronously "info:url#Retrieving URLs")
>     (url-retrieve-synchronously "man:cat")
> 
> I suggest support for such URLs is obsoleted, and that they are removed
> from (info "(url) Supported URL Types").

I don't see why we should.  Do they require any significant
maintenance effort to keep them?

Let's not obsolete/remove features just because we don't know who'd
need them.  Support for many features, some of them perhaps obscure to
many, is one of important traits of Emacs, so let's try keeping that
where it costs us little to do so.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58049; Package emacs. (Sun, 25 Sep 2022 14:02:02 GMT) Full text and rfc822 format available.

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

From: Augusto Stoffel <arstoffel <at> gmail.com>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 58049 <at> debbugs.gnu.org
Subject: Re: bug#58049: 29.0.50; Obsolete url schemes "info" and "man"
Date: Sun, 25 Sep 2022 16:01:20 +0200
On Sat, 24 Sep 2022 at 19:05, Stefan Kangas wrote:

> Severity: wishlist
>
> I don't think non-standard URLs like these are used much, and they're
> probably not very useful.  They're more likely to cause confusion.
>
>     (url-retrieve-synchronously "info:url#Retrieving URLs")
>     (url-retrieve-synchronously "man:cat")

I can imagine many uses for this.  For instance, a completion table
could provide some kind of "further info" property so you can preview
the documentation of an item mid-completion.  Also, and eldoc source
could provide a "further info" hyperlink pointing to the info or man
page.  (This is mostly speculation, of course.)

If I were to retire something, it would be the (file)node syntax for
info pages.

(My digestif TeX language server provides links to the documentation of
various packages, typically PDF files.  It checks if the PDF exists
locally and gives a file:// link, otherwise a https:// link to CTAN.
But it would be much better to just provide a “texinfo:” link and let
the editor decide how to display that.  Of course I don't do this
because no editor would support it OOTB, but I think the concept makes
sense.)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58049; Package emacs. (Sun, 25 Sep 2022 14:07:02 GMT) Full text and rfc822 format available.

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

From: Augusto Stoffel <arstoffel <at> gmail.com>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 58049 <at> debbugs.gnu.org
Subject: Re: bug#58049: 29.0.50; Obsolete url schemes "info" and "man"
Date: Sun, 25 Sep 2022 16:06:41 +0200
On Sun, 25 Sep 2022 at 16:01, Augusto Stoffel wrote:

> But it would be much better to just provide a “texinfo:” link and let

I meant “texdoc:” here (and the texdoc command would provide a way to
handle those hyperlinks.)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58049; Package emacs. (Sun, 25 Sep 2022 14:31:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Augusto Stoffel <arstoffel <at> gmail.com>
Cc: Stefan Kangas <stefankangas <at> gmail.com>, 58049 <at> debbugs.gnu.org
Subject: Re: bug#58049: 29.0.50; Obsolete url schemes "info" and "man"
Date: Sun, 25 Sep 2022 16:30:19 +0200
Augusto Stoffel <arstoffel <at> gmail.com> writes:

> I can imagine many uses for this.  For instance, a completion table
> could provide some kind of "further info" property so you can preview
> the documentation of an item mid-completion.

Why on Earth would you use URL syntax for something like that?  Just add
the "further info" property and link that up with a closure from a text
property or whatever

I'm all for retiring the info: and man: schemes (since they are 100%
useless), but don't really see the need to do so piecemeal -- when Emacs
grows a new URL library that functions better than the current one,
it'll only support http(s) and file, so all this junk will disappear in
one fell swoop.





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58049; Package emacs. (Sun, 25 Sep 2022 14:43:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: arstoffel <at> gmail.com, stefankangas <at> gmail.com, 58049 <at> debbugs.gnu.org
Subject: Re: bug#58049: 29.0.50; Obsolete url schemes "info" and "man"
Date: Sun, 25 Sep 2022 17:41:55 +0300
> Cc: Stefan Kangas <stefankangas <at> gmail.com>, 58049 <at> debbugs.gnu.org
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Sun, 25 Sep 2022 16:30:19 +0200
> 
> when Emacs grows a new URL library that functions better than the
> current one, it'll only support http(s) and file

You mean, no mailto:, no imap:, no irc:, no news:, no pop:, no rsync:,
etc.?  Do we really want to drop support for all those schemes?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58049; Package emacs. (Sun, 25 Sep 2022 14:47:01 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: arstoffel <at> gmail.com, stefankangas <at> gmail.com, 58049 <at> debbugs.gnu.org
Subject: Re: bug#58049: 29.0.50; Obsolete url schemes "info" and "man"
Date: Sun, 25 Sep 2022 16:46:01 +0200
Eli Zaretskii <eliz <at> gnu.org> writes:

> You mean, no mailto:, no imap:, no irc:, no news:, no pop:, no rsync:,
> etc.?  Do we really want to drop support for all those schemes?

From the new URL library?  Definitely -- the current URL library
hand-waves at handling some of those, but doesn't really, so there's
not much to drop.

(But other parts of Emacs handle mailto: just fine, and that'll continue
to work.)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58049; Package emacs. (Sun, 25 Sep 2022 15:11:02 GMT) Full text and rfc822 format available.

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Augusto Stoffel <arstoffel <at> gmail.com>
Cc: 58049 <at> debbugs.gnu.org
Subject: Re: bug#58049: 29.0.50; Obsolete url schemes "info" and "man"
Date: Sun, 25 Sep 2022 08:09:53 -0700
Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> I'm all for retiring the info: and man: schemes (since they are 100%
> useless), but don't really see the need to do so piecemeal -- when Emacs
> grows a new URL library that functions better than the current one,
> it'll only support http(s) and file, so all this junk will disappear in
> one fell swoop.

I think I agree.  Eli also has a point when he says that we might as
well just leave the support in.

How about saying in the URL manual that the info: and man: schemes as
deprecated, so people at least won't try to use them in new code?  That
is a small change, but will also potentially make the transition to
something new and improved a tiny bit easier.  It'll also discourage
anyone from attempting to re-implement it in the new library.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58049; Package emacs. (Sun, 25 Sep 2022 15:38:02 GMT) Full text and rfc822 format available.

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

From: Jean Louis <bugs <at> gnu.support>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 58049 <at> debbugs.gnu.org
Subject: Re: bug#58049: 29.0.50; Obsolete url schemes "info" and "man"
Date: Sun, 25 Sep 2022 14:52:27 +0300
* Stefan Kangas <stefankangas <at> gmail.com> [2022-09-25 02:07]:
> Severity: wishlist
> 
> I don't think non-standard URLs like these are used much, and they're
> probably not very useful.  They're more likely to cause confusion.
> 
>     (url-retrieve-synchronously "info:url#Retrieving URLs")
>     (url-retrieve-synchronously "man:cat")
> 
> I suggest support for such URLs is obsoleted, and that they are removed
> from (info "(url) Supported URL Types").

Please don't. There are many different URLs and you can't know how
users have implemented it. Yes, I agree they are less known, less
used, nevertheless it makes no sense to obsolete it.

Hyperlinking is major computing feature since Doug Engelbart, and the
fact that we have not implement it sufficiently does not mean it shall
be obsoleted.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58049; Package emacs. (Mon, 26 Sep 2022 10:53:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Augusto Stoffel <arstoffel <at> gmail.com>, 58049 <at> debbugs.gnu.org
Subject: Re: bug#58049: 29.0.50; Obsolete url schemes "info" and "man"
Date: Mon, 26 Sep 2022 12:51:59 +0200
Stefan Kangas <stefankangas <at> gmail.com> writes:

> How about saying in the URL manual that the info: and man: schemes as
> deprecated, so people at least won't try to use them in new code?  That
> is a small change, but will also potentially make the transition to
> something new and improved a tiny bit easier.  It'll also discourage
> anyone from attempting to re-implement it in the new library.

I'm not sure that's really that helpful -- they're not deprecated in any
"formal" sense, and I think the likelihood of them being reimplemented
is minuscule.





Reply sent to Stefan Kangas <stefankangas <at> gmail.com>:
You have taken responsibility. (Mon, 26 Sep 2022 11:16:02 GMT) Full text and rfc822 format available.

Notification sent to Stefan Kangas <stefankangas <at> gmail.com>:
bug acknowledged by developer. (Mon, 26 Sep 2022 11:16:02 GMT) Full text and rfc822 format available.

Message #37 received at 58049-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 58049-done <at> debbugs.gnu.org, Augusto Stoffel <arstoffel <at> gmail.com>
Subject: Re: bug#58049: 29.0.50; Obsolete url schemes "info" and "man"
Date: Mon, 26 Sep 2022 07:15:01 -0400
Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> I'm not sure that's really that helpful -- they're not deprecated in any
> "formal" sense, and I think the likelihood of them being reimplemented
> is minuscule.

Fair enough.  So I guess we want to leave this alone, and I'm closing
this bug.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58049; Package emacs. (Tue, 27 Sep 2022 06:22:02 GMT) Full text and rfc822 format available.

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

From: Jean Louis <bugs <at> gnu.support>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Augusto Stoffel <arstoffel <at> gmail.com>,
 Stefan Kangas <stefankangas <at> gmail.com>, 58049 <at> debbugs.gnu.org
Subject: Re: bug#58049: 29.0.50; Obsolete url schemes "info" and "man"
Date: Tue, 27 Sep 2022 09:00:02 +0300
* Lars Ingebrigtsen <larsi <at> gnus.org> [2022-09-25 17:32]:
> Augusto Stoffel <arstoffel <at> gmail.com> writes:
> 
> > I can imagine many uses for this.  For instance, a completion table
> > could provide some kind of "further info" property so you can preview
> > the documentation of an item mid-completion.
> 
> Why on Earth would you use URL syntax for something like that?  Just add
> the "further info" property and link that up with a closure from a text
> property or whatever
> 
> I'm all for retiring the info: and man: schemes (since they are 100%
> useless), but don't really see the need to do so piecemeal -- when Emacs
> grows a new URL library that functions better than the current one,
> it'll only support http(s) and file, so all this junk will disappear in
> one fell swoop.

Whatever you wish to remove, maybe I misunderstood it, but please do
not remove functionality from goto-address-mode that I can make any
kinds of links in Emacs buffers:

man:man is link here. I can open it as C-c RET and such links may be
automatically generated in my hyperlinking system, including many
other links.

URL schemes are standard, you do not just delete it because you do not
know how why on Earth would somebody use it.


Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58049; Package emacs. (Tue, 27 Sep 2022 18:03:02 GMT) Full text and rfc822 format available.

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Jean Louis <bugs <at> gnu.support>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Augusto Stoffel <arstoffel <at> gmail.com>, 58049 <at> debbugs.gnu.org
Subject: Re: bug#58049: 29.0.50; Obsolete url schemes "info" and "man"
Date: Tue, 27 Sep 2022 14:02:36 -0400
Jean Louis <bugs <at> gnu.support> writes:

> URL schemes are standard, you do not just delete it because you do not
> know how why on Earth would somebody use it.

This bug is already closed, but for the record these URI schemes are not
standard.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#58049; Package emacs. (Tue, 27 Sep 2022 21:18:02 GMT) Full text and rfc822 format available.

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

From: Jean Louis <bugs <at> gnu.support>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, Augusto Stoffel <arstoffel <at> gmail.com>,
 58049 <at> debbugs.gnu.org
Subject: Re: bug#58049: 29.0.50; Obsolete url schemes "info" and "man"
Date: Tue, 27 Sep 2022 23:23:33 +0300
* Stefan Kangas <stefankangas <at> gmail.com> [2022-09-27 21:07]:
> Jean Louis <bugs <at> gnu.support> writes:
> 
> > URL schemes are standard, you do not just delete it because you do not
> > know how why on Earth would somebody use it.
> 
> This bug is already closed, but for the record these URI schemes are not
> standard.

If not standard, not. 👀
-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Wed, 26 Oct 2022 11:24:11 GMT) Full text and rfc822 format available.

This bug report was last modified 1 year and 154 days ago.

Previous Next


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