bug#60190: 29.0.50; Improve `Info-goto-node-web'

bug#60190: 29.0.50; Improve `Info-goto-node-web'

[Marcin Borkowski]

Hi all,

I am extremely happy because of `Info-goto-node-web', but it would be
even better if two changes were made.

1. It could work in "An Introduction to Programming in Emacs Lisp" and
Org mode manual, too.

2. It could put the URL on the kill ring when called with a prefix
argument.

I would code these myself, but I changed jobs since I signed the FSF
paperwork long time ago, and I don't want to contribute to Emacs since
then because it could be a legal gray area then.  I think these two
changes are pretty low hanging fruit anyway.

Thanks!

PS. Please CC me on any replies to this request - I'm no longer
subscribed to the bug-gnu-emacs list.



In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.31, cairo version 1.17.4) of 2022-10-01 built on tars
Repository revision: c1eb13b32676b288a3ab3826501caf7bcd376b7f
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101003
System Description: Arch Linux

-- 
Marcin Borkowski
http://mbork.pl

bug#60190: 29.0.50; Improve `Info-goto-node-web'

[Eduardo Ochs]

On Mon, 19 Dec 2022 at 03:24, Marcin Borkowski <mbork@mbork.pl> wrote:
>
> Hi all,
>
> I am extremely happy because of `Info-goto-node-web', but it would be
> even better if two changes were made.
>
> 1. It could work in "An Introduction to Programming in Emacs Lisp" and
> Org mode manual, too.
>
> 2. It could put the URL on the kill ring when called with a prefix
> argument.
>
> I would code these myself, but I changed jobs since I signed the FSF
> paperwork long time ago, and I don't want to contribute to Emacs since
> then because it could be a legal gray area then.  I think these two
> changes are pretty low hanging fruit anyway.
>
> Thanks!
>
> PS. Please CC me on any replies to this request - I'm no longer
> subscribed to the bug-gnu-emacs list.


Hi Marcin and all,
what about this?

  (defvar Info-url-base
    '(("emacs"  . "http://www.gnu.org/software/emacs/manual/html_node/emacs/")
      ("elisp"  . "http://www.gnu.org/software/emacs/manual/html_node/elisp/")
      ("eintr"  .
"http://www.gnu.org/software/emacs/emacs-lisp-intro/html_node/")
      ("efaq"   . "https://www.gnu.org/software/emacs/manual/html_node/efaq/")
      ("cl"     . "http://www.gnu.org/software/emacs/manual/html_node/cl/")
      ("eshell" . "https://www.gnu.org/software/emacs/manual/html_node/eshell/")
      ("org"    . "http://www.gnu.org/software/emacs/manual/html_node/org/")))

  (defun Info-get-base-url (manual)
    (alist-get manual Info-url-base nil nil 'equal))

  (defun Info-url-for-node (node)
    "Return a URL for NODE, a node in the GNU Emacs or Elisp manual.
  NODE should be a string on the form \"(manual)Node\".  Only emacs
  and elisp manuals are supported."
    (unless (string-match "\\`(\\(.+\\))\\(.+\\)\\'" node)
      (error "Invalid node name %s" node))
    (let* ((manual (match-string 1 node))
           (node (match-string 2 node))
           (base-url (Info-get-base-url manual))) ; <- new
      ;; Old:
      ;; (unless (member manual '("emacs" "elisp"))
      ;;   (error "Only emacs/elisp manuals are supported"))
      ;; New:
      (if (not base-url)
          (error "Unsupported manual"))
      ;;
      ;; Encode a bunch of characters the way that makeinfo does.
      (setq node
            (mapconcat (lambda (ch)
                         (if (or (< ch 32)        ; ^@^A-^Z^[^\^]^^^-
                                 (<= 33 ch 47)    ; !"#$%&'()*+,-./
                                 (<= 58 ch 64)    ; :;<=>?@
                                 (<= 91 ch 96)    ; [\]_`
                                 (<= 123 ch 127)) ; {|}~ DEL
                             (format "_00%x" ch)
                           (char-to-string ch)))
                       node
                       ""))
      (concat base-url                    ; new
              (url-hexify-string (string-replace " " "-" node))
              ".html")))

Now the fruit hangs a little bit lower...
Cheers =),
  Eduardo Ochs
  http://angg.twu.net/eepitch.html

bug#60190: 29.0.50; Improve `Info-goto-node-web'

[Eli Zaretskii]

> Cc: 60190@debbugs.gnu.org
> From: Eduardo Ochs <eduardoochs@gmail.com>
> Date: Mon, 19 Dec 2022 04:02:47 -0300
> 
>   (defvar Info-url-base
>     '(("emacs"  . "http://www.gnu.org/software/emacs/manual/html_node/emacs/")
>       ("elisp"  . "http://www.gnu.org/software/emacs/manual/html_node/elisp/")
>       ("eintr"  .
> "http://www.gnu.org/software/emacs/emacs-lisp-intro/html_node/")
>       ("efaq"   . "https://www.gnu.org/software/emacs/manual/html_node/efaq/")
>       ("cl"     . "http://www.gnu.org/software/emacs/manual/html_node/cl/")
>       ("eshell" . "https://www.gnu.org/software/emacs/manual/html_node/eshell/")
>       ("org"    . "http://www.gnu.org/software/emacs/manual/html_node/org/")))

Aren't these mappings trivial?  You seem to be prepending the same
prefix to the exact name of the Info file (sans extension).  Or what
did I miss?

bug#60190: 29.0.50; Improve `Info-goto-node-web'

[Eduardo Ochs]

On Mon, 19 Dec 2022 at 09:31, Eli Zaretskii <eliz@gnu.org> wrote:
>
> > Cc: 60190@debbugs.gnu.org
> > From: Eduardo Ochs <eduardoochs@gmail.com>
> > Date: Mon, 19 Dec 2022 04:02:47 -0300
> >
> >   (defvar Info-url-base
> >     '(("emacs"  . "http://www.gnu.org/software/emacs/manual/html_node/emacs/")
> >       ("elisp"  . "http://www.gnu.org/software/emacs/manual/html_node/elisp/")
> >       ("eintr"  .
> > "http://www.gnu.org/software/emacs/emacs-lisp-intro/html_node/")
> >       ("efaq"   . "https://www.gnu.org/software/emacs/manual/html_node/efaq/")
> >       ("cl"     . "http://www.gnu.org/software/emacs/manual/html_node/cl/")
> >       ("eshell" . "https://www.gnu.org/software/emacs/manual/html_node/eshell/")
> >       ("org"    . "http://www.gnu.org/software/emacs/manual/html_node/org/")))
>
> Aren't these mappings trivial?  You seem to be prepending the same
> prefix to the exact name of the Info file (sans extension).  Or what
> did I miss?

No, look at the case of the eintr...

And if we use a table for the conversion then users can add new
entries to it easily, including entries that don't follow that
pattern. For example, this one:

  (add-to-alist 'Info-url-base
    '("slime" . "https://slime.common-lisp.dev/doc/html/"))

Cheers,
  Eduardo

bug#60190: 29.0.50; Improve `Info-goto-node-web'

[Eli Zaretskii]

> From: Eduardo Ochs <eduardoochs@gmail.com>
> Date: Mon, 19 Dec 2022 12:05:53 -0300
> Cc: mbork@mbork.pl, 60190@debbugs.gnu.org
> 
> On Mon, 19 Dec 2022 at 09:31, Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > Cc: 60190@debbugs.gnu.org
> > > From: Eduardo Ochs <eduardoochs@gmail.com>
> > > Date: Mon, 19 Dec 2022 04:02:47 -0300
> > >
> > >   (defvar Info-url-base
> > >     '(("emacs"  . "http://www.gnu.org/software/emacs/manual/html_node/emacs/")
> > >       ("elisp"  . "http://www.gnu.org/software/emacs/manual/html_node/elisp/")
> > >       ("eintr"  .
> > > "http://www.gnu.org/software/emacs/emacs-lisp-intro/html_node/")
> > >       ("efaq"   . "https://www.gnu.org/software/emacs/manual/html_node/efaq/")
> > >       ("cl"     . "http://www.gnu.org/software/emacs/manual/html_node/cl/")
> > >       ("eshell" . "https://www.gnu.org/software/emacs/manual/html_node/eshell/")
> > >       ("org"    . "http://www.gnu.org/software/emacs/manual/html_node/org/")))
> >
> > Aren't these mappings trivial?  You seem to be prepending the same
> > prefix to the exact name of the Info file (sans extension).  Or what
> > did I miss?
> 
> No, look at the case of the eintr...

Why is that necessary?  If you go to this page:

  https://www.gnu.org/software/emacs/manual/

you will see there a link to eintr which is this:

  https://www.gnu.org/software/emacs/manual/eintr.html

And if you follow it, you will find the manual itself at this URL:

  https://www.gnu.org/software/emacs/manual/html_node/eintr/index.html

which AFAIU doesn't require any database to generate.  Right?

> And if we use a table for the conversion then users can add new
> entries to it easily, including entries that don't follow that
> pattern.

I'm not against the table, I'm saying that for the manuals that come
with Emacs we don't need any entries in the table.  IOW, the table
could be provided, but only for extensions by users, if they want to
extend this to manuals which don't come as part of the Emacs
distribution.

bug#60190: 29.0.50; Improve `Info-goto-node-web'

[Stefan Kangas]

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

Eli Zaretskii <eliz@gnu.org> writes:

> I'm not against the table, I'm saying that for the manuals that come
> with Emacs we don't need any entries in the table.  IOW, the table
> could be provided, but only for extensions by users, if they want to
> extend this to manuals which don't come as part of the Emacs
> distribution.

I think we should include a list of built-in manuals, so that we only
send users to known-good places, and tell them otherwise.  The drawback
is that we need to remember to update the list when we add a new manual.

Perhaps something like the attached.

[-- Attachment #2: 0001-Make-Info-url-for-node-support-more-manuals.patch --]
[-- Type: text/x-diff, Size: 3510 bytes --]

From 9c14983767905260fb5a57543adc4c446e26cb92 Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefankangas@gmail.com>
Date: Tue, 20 Dec 2022 02:49:54 +0100
Subject: [PATCH 1/2] Make Info-url-for-node support more manuals

* lisp/info.el (info--url-for-node-manuals-built-in)
(info-url-for-node-manuals): New variables.
(Info-url-for-node): Support all built-in manuals, and add support
for external manuals.
---
 lisp/info.el | 44 +++++++++++++++++++++++++++++++++++---------
 1 file changed, 35 insertions(+), 9 deletions(-)

diff --git a/lisp/info.el b/lisp/info.el
index 05ad27e180..f939c42874 100644
--- a/lisp/info.el
+++ b/lisp/info.el
@@ -1793,16 +1793,43 @@ Info-goto-node-web
                                          Info-current-file))
                               node))))
 
+(defvar info--url-for-node-manuals-built-in
+  ;; All manuals are at https://www.gnu.org/software/emacs/manual/
+  '("auth" "autotype" "bovine" "calc" "ccmode" "cl" "dbus" "dired-x"
+    "ebrowse" "ede" "ediff" "edt" "efaq" "efaq-w32" "eglot" "eieio"
+    "eintr" "elisp" "emacs" "emacs-gnutls" "emacs-mime" "epa" "erc"
+    "ert" "eshell" "eudc" "eww" "faq" "flymake" "forms" "gnus"
+    "htmlfontify" "idlwave" "ido" "info" "mairix-el" "message" "mh-e"
+    "modus-themes" "newsticker" "nxml-mode" "octave-mode" "org"
+    "pcl-cvs" "pgg" "rcirc" "reftex" "remember" "sasl" "sc" "semantic"
+    "ses" "sieve" "smtpmail" "speedbar" "srecode" "todo-mode" "tramp"
+    "transient" "url" "use-package" "vhdl-mode" "vip" "viper" "widget"
+    "wisent" "woman")
+  "List of built-in manual names (strings) supported by `Info-url-for-node'.")
+
+(defvar info-url-for-node-manuals ()
+  "Alist of manuals for `Info-url-for-node'.
+Each entry has the form (NAME . URL) where NAME is the Info
+manual name, and URL is the canonical URL of the manual.
+The URL should not end in \"/\".")
+
 (defun Info-url-for-node (node)
-  "Return a URL for NODE, a node in the GNU Emacs or Elisp manual.
-NODE should be a string on the form \"(manual)Node\".  Only emacs
-and elisp manuals are supported."
+  "Return a URL for NODE, a node in the current manual.
+NODE should be a string on the form \"(manual)Node\".
+
+All built-in manuals are supported by default, but additional
+manuals can be added to the variable `info-url-for-node-manuals'."
   (unless (string-match "\\`(\\(.+\\))\\(.+\\)\\'" node)
     (error "Invalid node name %s" node))
-  (let ((manual (match-string 1 node))
-        (node (match-string 2 node)))
-    (unless (member manual '("emacs" "elisp"))
-      (error "Only emacs/elisp manuals are supported"))
+  (let* ((manual (match-string 1 node))
+         (node (match-string 2 node))
+         (base-url
+          (or (assoc manual info-url-for-node-manuals)
+              (and (member manual info--url-for-node-manuals-built-in)
+                   "https://www.gnu.org/software/emacs/manual/html_node")
+              (error "Manual not supported: %s" manual))))
+    (when (equal node "Top")
+      (setq node "index"))
     ;; Encode a bunch of characters the way that makeinfo does.
     (setq node
           (mapconcat (lambda (ch)
@@ -1815,8 +1842,7 @@ Info-url-for-node
                          (char-to-string ch)))
                      node
                      ""))
-    (concat "https://www.gnu.org/software/emacs/manual/html_node/"
-            manual "/"
+    (concat base-url "/" manual "/"
             (url-hexify-string (string-replace " " "-" node))
             ".html")))
 
-- 
2.35.1

bug#60190: 29.0.50; Improve `Info-goto-node-web'

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Mon, 19 Dec 2022 22:44:41 -0600
> Cc: 60190@debbugs.gnu.org, mbork@mbork.pl
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I'm not against the table, I'm saying that for the manuals that come
> > with Emacs we don't need any entries in the table.  IOW, the table
> > could be provided, but only for extensions by users, if they want to
> > extend this to manuals which don't come as part of the Emacs
> > distribution.
> 
> I think we should include a list of built-in manuals, so that we only
> send users to known-good places, and tell them otherwise.  The drawback
> is that we need to remember to update the list when we add a new manual.

There's no need to maintain a list, we can produce it at build time by
looking at the DIR file we produce in the info subdirectory.  This
would solve the maintenance problem cleanly and easily.

bug#60190: 29.0.50; Improve `Info-goto-node-web'

[Eduardo Ochs]

On Tue, 20 Dec 2022 at 11:02, Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Stefan Kangas <stefankangas@gmail.com>
> > Date: Mon, 19 Dec 2022 22:44:41 -0600
> > Cc: 60190@debbugs.gnu.org, mbork@mbork.pl
> >
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> > > I'm not against the table, I'm saying that for the manuals that come
> > > with Emacs we don't need any entries in the table.  IOW, the table
> > > could be provided, but only for extensions by users, if they want to
> > > extend this to manuals which don't come as part of the Emacs
> > > distribution.
> >
> > I think we should include a list of built-in manuals, so that we only
> > send users to known-good places, and tell them otherwise.  The drawback
> > is that we need to remember to update the list when we add a new manual.
>
> There's no need to maintain a list, we can produce it at build time by
> looking at the DIR file we produce in the info subdirectory.  This
> would solve the maintenance problem cleanly and easily.

How would that work for packages that are in MELPA? Some of them have
Info manuals that can be accessed on the web, but that are in
random(ish) places...

  Cheers,
    Eduardo Ochs
    http://angg.twu.net/eepitch.html

bug#60190: 29.0.50; Improve `Info-goto-node-web'

[Eli Zaretskii]

> From: Eduardo Ochs <eduardoochs@gmail.com>
> Date: Tue, 20 Dec 2022 12:20:41 -0300
> Cc: Stefan Kangas <stefankangas@gmail.com>, 60190@debbugs.gnu.org, mbork@mbork.pl
> 
> On Tue, 20 Dec 2022 at 11:02, Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > From: Stefan Kangas <stefankangas@gmail.com>
> > > Date: Mon, 19 Dec 2022 22:44:41 -0600
> > > Cc: 60190@debbugs.gnu.org, mbork@mbork.pl
> > >
> > > Eli Zaretskii <eliz@gnu.org> writes:
> > >
> > > > I'm not against the table, I'm saying that for the manuals that come
> > > > with Emacs we don't need any entries in the table.  IOW, the table
> > > > could be provided, but only for extensions by users, if they want to
> > > > extend this to manuals which don't come as part of the Emacs
> > > > distribution.
> > >
> > > I think we should include a list of built-in manuals, so that we only
> > > send users to known-good places, and tell them otherwise.  The drawback
> > > is that we need to remember to update the list when we add a new manual.
> >
> > There's no need to maintain a list, we can produce it at build time by
> > looking at the DIR file we produce in the info subdirectory.  This
> > would solve the maintenance problem cleanly and easily.
> 
> How would that work for packages that are in MELPA?

It isn't intended to work for those, it is only intended to work for
manuals that come with Emacs.  For the others, we are back at the
extensibility features, which is a separate feature.

bug#60190: 29.0.50; Improve `Info-goto-node-web'

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> There's no need to maintain a list, we can produce it at build time by
> looking at the DIR file we produce in the info subdirectory.  This
> would solve the maintenance problem cleanly and easily.

OK, we could do that.

What would be the cleanest way to make that information available to
Lisp?  Do we just generate a new file at build-time and put it there, or
is there a better way?

bug#60190: 29.0.50; Improve `Info-goto-node-web'

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Tue, 20 Dec 2022 19:05:01 -0600
> Cc: eduardoochs@gmail.com, 60190@debbugs.gnu.org, mbork@mbork.pl
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > There's no need to maintain a list, we can produce it at build time by
> > looking at the DIR file we produce in the info subdirectory.  This
> > would solve the maintenance problem cleanly and easily.
> 
> OK, we could do that.
> 
> What would be the cleanest way to make that information available to
> Lisp?  Do we just generate a new file at build-time and put it there, or
> is there a better way?

I'd think we could generate a info-something.eld file that would then
be installed by "make install" and read by info.el when this command
is invoked.  WDYT?

bug#60190: 29.0.50; Improve `Info-goto-node-web'

[Drew Adams]

> I am extremely happy because of `Info-goto-node-web', but it would be
> even better if two changes were made.
> 
> 1. It could work in "An Introduction to Programming in Emacs Lisp" and
> Org mode manual, too.
> 
> 2. It could put the URL on the kill ring when called with a prefix
> argument.

FWIW:

The command is originally from Info+ (see bug #44895).

There, a prefix arg reverses the effect of the current
value of option `browse-url-new-window-flag', which
decides whether a new browser window is used instead
of the current one.
___

A prefix arg could (1) do that or (2) use a separate
browser tab, and also (3) do what you ask, depending
on its value (e.g., plain C-u, plain -, =< 0, >= 0).

Or there could be separate commands
(*-other-tab|window|frame), since vanilla Emacs
doesn't like to let a prefix arg do multiple things.
___

And an option could decide whether by default the URL
is copied to the kill-ring (prefix arg here flipping
that behavior).

And maybe the option should cover not only this
command but also commands that read a URL - IOW,
maybe it should be a general user preference
whether to add URLs (that you choose interactively)
to the kill-ring.
___

I agree with Eli that it would be good for any list
of manuals to use to be the value of a (user)
variable, as opposed to being hardcoded.

Its default value should come (at runtime) from the
manuals you get by default in your context (it can
vary a lot).  E.g., ` info--manual-names', which
can be limited to the manuals currently visited.
___


https://www.emacswiki.org/emacs/InfoPlus

bug#60190: 29.0.50; Improve `Info-goto-node-web'

[Marcin Borkowski]

On 2022-12-19, at 18:23, Drew Adams <drew.adams@oracle.com> wrote:

>> I am extremely happy because of `Info-goto-node-web', but it would be
>> even better if two changes were made.
>> 
>> 1. It could work in "An Introduction to Programming in Emacs Lisp" and
>> Org mode manual, too.
>> 
>> 2. It could put the URL on the kill ring when called with a prefix
>> argument.
>
> FWIW:
>
> The command is originally from Info+ (see bug #44895).

Interesting, though not surprising.

> There, a prefix arg reverses the effect of the current
> value of option `browse-url-new-window-flag', which
> decides whether a new browser window is used instead
> of the current one.

Out of curiosity – is it possible to decide that when calling
e.g. Firefox?  (Frankly, I'm not sure why I would want a separate window
when ff has tabs, but maybe some people do use windows...)

> And maybe the option should cover not only this
> command but also commands that read a URL - IOW,
> maybe it should be a general user preference
> whether to add URLs (that you choose interactively)
> to the kill-ring.

Not sure about this – why put a URL I _type_ into the kill ring?  Though
I agree that if the URL is somehow generated, this may be very useful.
For instance, if I had a function which could open DevDocs pages,
copying their URLs to the kill ring (or in this case, the system
clipboard) could make it easier to send their links to my teammates
(something I do fairly often).

Best,

-- 
Marcin Borkowski
http://mbork.pl

bug#60190: 29.0.50; Improve `Info-goto-node-web'

[Drew Adams]

> > There, a prefix arg reverses the effect of the current
> > value of option `browse-url-new-window-flag', which
> > decides whether a new browser window is used instead
> > of the current one.
> 
> Out of curiosity – is it possible to decide that when calling
> e.g. Firefox?

Dunno, but I'd guess so.  Since the first web
browsers it's typically been possible to open a
URL in a new browser window or an existing one.

info+.el hands off that bit to `browse-url.el'.
That's the helper for browsing URLs with web
browsers.  If it can't also open a URL in a tab
then maybe that feature should be added to it.

> (Frankly, I'm not sure why I would want a separate window
> when ff has tabs, but maybe some people do use windows...)

I use both tabs and separate windows with web browsers,
e.g., Firefox and Chrome (e.g. Brave).

Maybe you just have one browser window.  Maybe
you have it full-screen.  To me, that would be
quite limiting, but we all have our preferences.

> > And maybe the option should cover not only this
> > command but also commands that read a URL - IOW,
> > maybe it should be a general user preference
> > whether to add URLs (that you choose interactively)
> > to the kill-ring.
> 
> Not sure about this – why put a URL I _type_ into the kill ring?  Though
> I agree that if the URL is somehow generated, this may be very useful.
> For instance, if I had a function which could open DevDocs pages,
> copying their URLs to the kill ring (or in this case, the system
> clipboard) could make it easier to send their links to my teammates
> (something I do fairly often).

Why?  Why not?  Why type it twice or more?

Not saying I'd use such a feature, or how much I
would. But I can imagine that some users might.
Till now I might not have thought that someone
would want what you request: add the URL to the
kill-ring for the Info case.

IOW, I'm not sure either.  But if we're starting
to think about such things then we might as well
think them through a bit.

bug#60190: 29.0.50; Improve `Info-goto-node-web'

[Marcin Borkowski]

On 2022-12-19, at 21:33, Drew Adams <drew.adams@oracle.com> wrote:

>> > And maybe the option should cover not only this
>> > command but also commands that read a URL - IOW,
>> > maybe it should be a general user preference
>> > whether to add URLs (that you choose interactively)
>> > to the kill-ring.
>>
>> Not sure about this – why put a URL I _type_ into the kill ring?  Though
>> I agree that if the URL is somehow generated, this may be very useful.
>> For instance, if I had a function which could open DevDocs pages,
>> copying their URLs to the kill ring (or in this case, the system
>> clipboard) could make it easier to send their links to my teammates
>> (something I do fairly often).
>
> Why?  Why not?  Why type it twice or more?

Because if I "typed" it (read: put it there myself), it means that most
probably I just yanked it anyway, so why put it again onto the kill
ring?

> Not saying I'd use such a feature, or how much I
> would. But I can imagine that some users might.
> Till now I might not have thought that someone
> would want what you request: add the URL to the
> kill-ring for the Info case.
>
> IOW, I'm not sure either.  But if we're starting
> to think about such things then we might as well
> think them through a bit.

100% agree.

-- 
Marcin Borkowski
http://mbork.pl