bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#67615: [PATCH v2] * lisp/info.el (Info-url-for-node): Support all Em


From: Eli Zaretskii
Subject: bug#67615: [PATCH v2] * lisp/info.el (Info-url-for-node): Support all Emacs info manuals.
Date: Thu, 07 Dec 2023 19:02:15 +0200

> From: Mekeor Melire <mekeor@posteo.de>
> Cc: rms@gnu.org, 67615@debbugs.gnu.org
> Date: Thu, 07 Dec 2023 11:56:34 +0000
> 
> 2023-12-07 09:19 eliz@gnu.org:
> 
> > We decided first to support manuals that come with Emacs, and Gawk's
> > manual doesn't.
> >
> > Supporting all GNU manuals is a much larger job, since there's no
> > single base URL from which they all can be reached (although many of
> > them can be reached from the GNU site).  Also, the arrangement of the
> > manuals of the other packages is slightly different from that of
> > Emacs, which needs more specialized processing.
> 
> It would be of great help if the administrators of gnu.org could provide
> a strict pattern for online-manual-URLs on gnu.org. Additionally, it'd
> be nice if gnu.org would not only provide the manual for the latest
> version of GNU packages, but also for prior versions. This would allow
> Emacs' info.el to browse the version-matching online-manual
> corresponding to the locally-installed, currently-read Emacs-included
> manual. But all of this needs to be discussed on another mailing-list,
> related to the administration of gnu.org.

I think each GNU project uses slightly different arrangements.  Also,
how exactly the HTML manuals are arranged on gnu.org is up to the
projects, not gnu.org admmins (which just provide technical support).
In any case, this is not the right place to talk about GNU-wide
conventions and decisions.

> > So I think for now it should be enough to have only the Emacs manuals
> > by default, and let users add more associations for other packages if
> > they like.
> 
> By the way, I'm planning to release a FSF-assigned Emacs-package
> providing more associations.

That is okay, but one problem with such associations is the need to
maintain them so they remain accurate, tracking whatever changes in
other GNU projects that could affect this.  This is one reason I
suggested that we stop short of doing that, and only limit ourselves
to the manuals which we control.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]