GNU bug report logs - #60190
29.0.50; Improve `Info-goto-node-web'

Previous Next

Package: emacs;

Reported by: Marcin Borkowski <mbork <at> mbork.pl>

Date: Mon, 19 Dec 2022 06:24:02 UTC

Severity: wishlist

Found in version 29.0.50

To reply to this bug, email your comments to 60190 AT debbugs.gnu.org.

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#60190; Package emacs. (Mon, 19 Dec 2022 06:24:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Marcin Borkowski <mbork <at> mbork.pl>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Mon, 19 Dec 2022 06:24:02 GMT) Full text and rfc822 format available.

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

From: Marcin Borkowski <mbork <at> mbork.pl>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; Improve `Info-goto-node-web'
Date: Mon, 19 Dec 2022 07:23:32 +0100
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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60190; Package emacs. (Mon, 19 Dec 2022 07:04:01 GMT) Full text and rfc822 format available.

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

From: Eduardo Ochs <eduardoochs <at> gmail.com>
To: Marcin Borkowski <mbork <at> mbork.pl>
Cc: 60190 <at> debbugs.gnu.org
Subject: Re: bug#60190: 29.0.50; Improve `Info-goto-node-web'
Date: Mon, 19 Dec 2022 04:02:47 -0300
On Mon, 19 Dec 2022 at 03:24, Marcin Borkowski <mbork <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60190; Package emacs. (Mon, 19 Dec 2022 12:32:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eduardo Ochs <eduardoochs <at> gmail.com>
Cc: 60190 <at> debbugs.gnu.org, mbork <at> mbork.pl
Subject: Re: bug#60190: 29.0.50; Improve `Info-goto-node-web'
Date: Mon, 19 Dec 2022 14:31:30 +0200
> Cc: 60190 <at> debbugs.gnu.org
> From: Eduardo Ochs <eduardoochs <at> 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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60190; Package emacs. (Mon, 19 Dec 2022 15:07:02 GMT) Full text and rfc822 format available.

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

From: Eduardo Ochs <eduardoochs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 60190 <at> debbugs.gnu.org, mbork <at> mbork.pl
Subject: Re: bug#60190: 29.0.50; Improve `Info-goto-node-web'
Date: Mon, 19 Dec 2022 12:05:53 -0300
On Mon, 19 Dec 2022 at 09:31, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > Cc: 60190 <at> debbugs.gnu.org
> > From: Eduardo Ochs <eduardoochs <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60190; Package emacs. (Mon, 19 Dec 2022 15:28:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eduardo Ochs <eduardoochs <at> gmail.com>
Cc: 60190 <at> debbugs.gnu.org, mbork <at> mbork.pl
Subject: Re: bug#60190: 29.0.50; Improve `Info-goto-node-web'
Date: Mon, 19 Dec 2022 17:27:42 +0200
> From: Eduardo Ochs <eduardoochs <at> gmail.com>
> Date: Mon, 19 Dec 2022 12:05:53 -0300
> Cc: mbork <at> mbork.pl, 60190 <at> debbugs.gnu.org
> 
> On Mon, 19 Dec 2022 at 09:31, Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> > > Cc: 60190 <at> debbugs.gnu.org
> > > From: Eduardo Ochs <eduardoochs <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60190; Package emacs. (Mon, 19 Dec 2022 17:24:02 GMT) Full text and rfc822 format available.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Marcin Borkowski <mbork <at> mbork.pl>, "60190 <at> debbugs.gnu.org"
 <60190 <at> debbugs.gnu.org>
Subject: RE: [External] : bug#60190: 29.0.50; Improve `Info-goto-node-web'
Date: Mon, 19 Dec 2022 17:23:07 +0000
> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60190; Package emacs. (Mon, 19 Dec 2022 19:25:02 GMT) Full text and rfc822 format available.

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

From: Marcin Borkowski <mbork <at> mbork.pl>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: "60190 <at> debbugs.gnu.org" <60190 <at> debbugs.gnu.org>
Subject: Re: [External] : bug#60190: 29.0.50; Improve `Info-goto-node-web'
Date: Mon, 19 Dec 2022 20:24:00 +0100
On 2022-12-19, at 18:23, Drew Adams <drew.adams <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60190; Package emacs. (Mon, 19 Dec 2022 20:34:02 GMT) Full text and rfc822 format available.

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Marcin Borkowski <mbork <at> mbork.pl>
Cc: "60190 <at> debbugs.gnu.org" <60190 <at> debbugs.gnu.org>
Subject: RE: [External] : bug#60190: 29.0.50; Improve `Info-goto-node-web'
Date: Mon, 19 Dec 2022 20:33:43 +0000
> > 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.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60190; Package emacs. (Tue, 20 Dec 2022 04:45:02 GMT) Full text and rfc822 format available.

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Eduardo Ochs <eduardoochs <at> gmail.com>
Cc: 60190 <at> debbugs.gnu.org, mbork <at> mbork.pl
Subject: Re: bug#60190: 29.0.50; Improve `Info-goto-node-web'
Date: Mon, 19 Dec 2022 22:44:41 -0600
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> 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.
[0001-Make-Info-url-for-node-support-more-manuals.patch (text/x-diff, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60190; Package emacs. (Tue, 20 Dec 2022 06:01:02 GMT) Full text and rfc822 format available.

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

From: Marcin Borkowski <mbork <at> mbork.pl>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: "60190 <at> debbugs.gnu.org" <60190 <at> debbugs.gnu.org>
Subject: Re: [External] : bug#60190: 29.0.50; Improve `Info-goto-node-web'
Date: Tue, 20 Dec 2022 07:00:40 +0100
On 2022-12-19, at 21:33, Drew Adams <drew.adams <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60190; Package emacs. (Tue, 20 Dec 2022 14:03:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 60190 <at> debbugs.gnu.org, mbork <at> mbork.pl, eduardoochs <at> gmail.com
Subject: Re: bug#60190: 29.0.50; Improve `Info-goto-node-web'
Date: Tue, 20 Dec 2022 16:02:13 +0200
> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Mon, 19 Dec 2022 22:44:41 -0600
> Cc: 60190 <at> debbugs.gnu.org, mbork <at> mbork.pl
> 
> Eli Zaretskii <eliz <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60190; Package emacs. (Tue, 20 Dec 2022 15:21:02 GMT) Full text and rfc822 format available.

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

From: Eduardo Ochs <eduardoochs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 60190 <at> debbugs.gnu.org, mbork <at> mbork.pl,
 Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#60190: 29.0.50; Improve `Info-goto-node-web'
Date: Tue, 20 Dec 2022 12:20:41 -0300
On Tue, 20 Dec 2022 at 11:02, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Stefan Kangas <stefankangas <at> gmail.com>
> > Date: Mon, 19 Dec 2022 22:44:41 -0600
> > Cc: 60190 <at> debbugs.gnu.org, mbork <at> mbork.pl
> >
> > Eli Zaretskii <eliz <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60190; Package emacs. (Tue, 20 Dec 2022 15:34:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eduardo Ochs <eduardoochs <at> gmail.com>
Cc: 60190 <at> debbugs.gnu.org, mbork <at> mbork.pl, stefankangas <at> gmail.com
Subject: Re: bug#60190: 29.0.50; Improve `Info-goto-node-web'
Date: Tue, 20 Dec 2022 17:33:57 +0200
> From: Eduardo Ochs <eduardoochs <at> gmail.com>
> Date: Tue, 20 Dec 2022 12:20:41 -0300
> Cc: Stefan Kangas <stefankangas <at> gmail.com>, 60190 <at> debbugs.gnu.org, mbork <at> mbork.pl
> 
> On Tue, 20 Dec 2022 at 11:02, Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> > > From: Stefan Kangas <stefankangas <at> gmail.com>
> > > Date: Mon, 19 Dec 2022 22:44:41 -0600
> > > Cc: 60190 <at> debbugs.gnu.org, mbork <at> mbork.pl
> > >
> > > Eli Zaretskii <eliz <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60190; Package emacs. (Wed, 21 Dec 2022 01:06:01 GMT) Full text and rfc822 format available.

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 60190 <at> debbugs.gnu.org, mbork <at> mbork.pl, eduardoochs <at> gmail.com
Subject: Re: bug#60190: 29.0.50; Improve `Info-goto-node-web'
Date: Tue, 20 Dec 2022 19:05:01 -0600
Eli Zaretskii <eliz <at> 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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#60190; Package emacs. (Wed, 21 Dec 2022 12:05:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 60190 <at> debbugs.gnu.org, mbork <at> mbork.pl, eduardoochs <at> gmail.com
Subject: Re: bug#60190: 29.0.50; Improve `Info-goto-node-web'
Date: Wed, 21 Dec 2022 14:04:01 +0200
> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Tue, 20 Dec 2022 19:05:01 -0600
> Cc: eduardoochs <at> gmail.com, 60190 <at> debbugs.gnu.org, mbork <at> mbork.pl
> 
> Eli Zaretskii <eliz <at> 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?




Severity set to 'wishlist' from 'normal' Request was from Stefan Kangas <stefankangas <at> gmail.com> to control <at> debbugs.gnu.org. (Mon, 04 Sep 2023 15:11:01 GMT) Full text and rfc822 format available.

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

Previous Next


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