* Proposal: Include C Manual from RMS in Emacs git, and/or release
@ 2024-11-30 12:56 Jeremy Bryant
2024-11-30 13:25 ` Philip Kaludercic
` (2 more replies)
0 siblings, 3 replies; 56+ messages in thread
From: Jeremy Bryant @ 2024-11-30 12:56 UTC (permalink / raw)
To: Emacs Devel, Richard Stallman
Dear RMS and other maintainers,
The C manual at
https://savannah.gnu.org/projects/c-intro-and-ref/
1.
could be a useful guide to include within the Emacs tree under doc/
2.
It could possibly be part of the release tarball given the usefulness of
Emacs for C programmers?
3.
Or ELPA?
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Proposal: Include C Manual from RMS in Emacs git, and/or release
2024-11-30 12:56 Proposal: Include C Manual from RMS in Emacs git, and/or release Jeremy Bryant
@ 2024-11-30 13:25 ` Philip Kaludercic
2024-11-30 13:38 ` Arsen Arsenović
2024-11-30 13:50 ` Eli Zaretskii
2 siblings, 0 replies; 56+ messages in thread
From: Philip Kaludercic @ 2024-11-30 13:25 UTC (permalink / raw)
To: Jeremy Bryant; +Cc: Emacs Devel, Richard Stallman
Jeremy Bryant <jb@jeremybryant.net> writes:
> Dear RMS and other maintainers,
>
> The C manual at
> https://savannah.gnu.org/projects/c-intro-and-ref/
>
> 1.
> could be a useful guide to include within the Emacs tree under doc/
> 2.
> It could possibly be part of the release tarball given the usefulness of
> Emacs for C programmers?
> 3.
> Or ELPA?
I don't know how useful it is for Emacs, but it should be more-or-less
easy to have it available via ELPA (of course a separate distribution
system for high-quality TeXinfo manuals would be even more preferable,
but I don't know of anything like that).
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Proposal: Include C Manual from RMS in Emacs git, and/or release
2024-11-30 12:56 Proposal: Include C Manual from RMS in Emacs git, and/or release Jeremy Bryant
2024-11-30 13:25 ` Philip Kaludercic
@ 2024-11-30 13:38 ` Arsen Arsenović
2024-11-30 14:12 ` Eli Zaretskii
2024-11-30 13:50 ` Eli Zaretskii
2 siblings, 1 reply; 56+ messages in thread
From: Arsen Arsenović @ 2024-11-30 13:38 UTC (permalink / raw)
To: Jeremy Bryant; +Cc: Emacs Devel, Richard Stallman
[-- Attachment #1: Type: text/plain, Size: 1013 bytes --]
Jeremy Bryant <jb@jeremybryant.net> writes:
> Dear RMS and other maintainers,
I'm neither, but I hope my feedback is appreciated anyway :-)
> The C manual at
> https://savannah.gnu.org/projects/c-intro-and-ref/
>
> 1.
> could be a useful guide to include within the Emacs tree under doc/
I don't see how.
> 2.
> It could possibly be part of the release tarball given the usefulness of
> Emacs for C programmers?
Generally, bundling stuff makes it hard to distribute independently.
For instance, many distributions do not install info.info with standalne
'info' as it is part of Emacs, which IMO has damaged the reputation of
the Texinfo documentation system, as anyone who does not have emacs
installed, or, worse, emacses non-DFSG documentation package could not
access the tutorial or manual.
> 3.
> Or ELPA?
I don't see the point to that personally, but at least it won't create
the trouble bundling (like info.info) creates.
Have a lovely day.
--
Arsen Arsenović
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Proposal: Include C Manual from RMS in Emacs git, and/or release
2024-11-30 12:56 Proposal: Include C Manual from RMS in Emacs git, and/or release Jeremy Bryant
2024-11-30 13:25 ` Philip Kaludercic
2024-11-30 13:38 ` Arsen Arsenović
@ 2024-11-30 13:50 ` Eli Zaretskii
2024-12-01 4:02 ` Sean Whitton
2024-12-02 4:10 ` Proposal: Include C Manual from RMS in Emacs git, and/or release Richard Stallman
2 siblings, 2 replies; 56+ messages in thread
From: Eli Zaretskii @ 2024-11-30 13:50 UTC (permalink / raw)
To: Jeremy Bryant; +Cc: emacs-devel, rms
> From: Jeremy Bryant <jb@jeremybryant.net>
> Date: Sat, 30 Nov 2024 12:56:19 +0000
>
> Dear RMS and other maintainers,
>
> The C manual at
> https://savannah.gnu.org/projects/c-intro-and-ref/
>
> 1.
> could be a useful guide to include within the Emacs tree under doc/
> 2.
> It could possibly be part of the release tarball given the usefulness of
> Emacs for C programmers?
> 3.
> Or ELPA?
FWIW, I don't think this (IMO very useful and installed on my
machines) manual belongs to Emacs. It should be a separate manual.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Proposal: Include C Manual from RMS in Emacs git, and/or release
2024-11-30 13:38 ` Arsen Arsenović
@ 2024-11-30 14:12 ` Eli Zaretskii
2024-11-30 18:08 ` Arsen Arsenović
0 siblings, 1 reply; 56+ messages in thread
From: Eli Zaretskii @ 2024-11-30 14:12 UTC (permalink / raw)
To: Arsen Arsenović; +Cc: jb, emacs-devel, rms
> From: Arsen Arsenović <arsen@aarsen.me>
> Cc: Emacs Devel <emacs-devel@gnu.org>, Richard Stallman <rms@gnu.org>
> Date: Sat, 30 Nov 2024 14:38:42 +0100
>
> For instance, many distributions do not install info.info with standalne
> 'info' as it is part of Emacs, which IMO has damaged the reputation of
> the Texinfo documentation system, as anyone who does not have emacs
> installed, or, worse, emacses non-DFSG documentation package could not
> access the tutorial or manual.
The Info tutorial was moved to Emacs because Emacs is de-facto the
only Info reader in wide use. Texinfo comes with info-stnd.info,
which documents the stand-alone reader, which is part of Texinfo.
So I don't see how that move could damage the reputation of Texinfo.
Do you have any information to suggest that many people use the
stand-alone reader?
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Proposal: Include C Manual from RMS in Emacs git, and/or release
2024-11-30 14:12 ` Eli Zaretskii
@ 2024-11-30 18:08 ` Arsen Arsenović
2024-11-30 20:05 ` Eli Zaretskii
0 siblings, 1 reply; 56+ messages in thread
From: Arsen Arsenović @ 2024-11-30 18:08 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: jb, emacs-devel, rms
Hi Eli,
<#secure method=pgpmime mode=sign>
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Arsen Arsenović <arsen@aarsen.me>
>> Cc: Emacs Devel <emacs-devel@gnu.org>, Richard Stallman <rms@gnu.org>
>> Date: Sat, 30 Nov 2024 14:38:42 +0100
>>
>> For instance, many distributions do not install info.info with standalne
>> 'info' as it is part of Emacs, which IMO has damaged the reputation of
>> the Texinfo documentation system, as anyone who does not have emacs
>> installed, or, worse, emacses non-DFSG documentation package could not
>> access the tutorial or manual.
>
> The Info tutorial was moved to Emacs because Emacs is de-facto the
> only Info reader in wide use.
I see no way to back up that statement. Emacs is certainly not the only
Info reader in wide use. In fact, I'd wager the standalone info reader
is far more widespread.
Not that it matters - there _is_ another info reader, that's meant to be
compatible, and currently, for the sake of Emacs, its self-documentation
is subpar.
> Texinfo comes with info-stnd.info, which documents the stand-alone
> reader, which is part of Texinfo.
... which also lacks the tutorial section. In fact, the standalone info
readers manual starts with talking about the Emacs info reader, tells
you to navigate via <SPC> and <DEL> (which is good! that should be
front and center), and then jumps into "node navigation" without
covering what a node is. This is fine for a reference manual, but it
gets opened when one asks for a tutorial.
> So I don't see how that move could damage the reputation of Texinfo.
Emacs is extremely niche, while reading the documentation of various GNU
packages is not. Ergo, we recommend people to read documentation using
info (see e.g. help2man generated output) - as we should.
As a result, on many systems (no complete empirical data for obvious
reasons, but at least on *all* Debian systems without the nonfree
repositories enabled, which is already quite a few systems - in fact,
looking at popcon, 13.64% of Debian systems have 'info' installed, only
6.68% have emacs-common, and 0.33% have emacs-common-non-dfsg, which is,
sadly, where info.info is[1][2]), a user will type 'info ls' or such,
get confused when the node being observed changes while they were
holding arrow-down, remember that the viewer told them to hit 'h' to
read a tutorial, then hit 'h', and silently fail to get a tutorial.
This is especially bad because there's more up-front cognitive load when
trying to use info: it has a hierarchical structure, opposed to the
awful flat page 'man' provides, and it is also a hypertext, so it can be
overwhelming initially.
I recommend Texinfo constantly, because I've observed that Texinfo is a
better documentation system among the existing Unix-ish documentation
systems, and this observation seems to be made by others if I take the
time to walk them through how to use 'info' (or M-x info if they're
using Emacs also).
> Do you have any information to suggest that many people use the
> stand-alone reader?
Do you have information to suggest that many people use the in-Emacs
reader? I certainly do use it, so we can put that a mark on the
chalkboard.
My information comes from years of recommending people to try Texinfo
(and indeed recommending both readers as I do), but that's anecdotal.
Debians popcon seems to agree, though.
Obviously, popcon does not measure /use/, but it does measure un-use, as
someone who does not install a package cannot use it (except for manual
installation.. I doubt that's statistically significant).
The standalone info reader is also what GNU manpages recommend (to
preempt anyone questioning whether those matter because they are
best-effort: yes, they do, because a lot of people are accustomed to
checking 'man $cmd' and are told or trained to do that).
In conclusion, I'd wager a quality standalone reader is more important
than a quality info.el in a head-to-head comparison. Asking
distributors to move info.info into a standalone package would be a step
in the right direction.
Have a lovely day.
[1] https://qa.debian.org/popcon.php?package=emacs
[2] https://qa.debian.org/popcon.php?package=emacs-non-dfsg
--
Arsen Arsenović
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Proposal: Include C Manual from RMS in Emacs git, and/or release
2024-11-30 18:08 ` Arsen Arsenović
@ 2024-11-30 20:05 ` Eli Zaretskii
2024-11-30 21:09 ` [External] : " Drew Adams
` (2 more replies)
0 siblings, 3 replies; 56+ messages in thread
From: Eli Zaretskii @ 2024-11-30 20:05 UTC (permalink / raw)
To: Arsen Arsenović; +Cc: jb, emacs-devel, rms
> From: Arsen Arsenović <arsen@aarsen.me>
> Cc: jb@jeremybryant.net, emacs-devel@gnu.org, rms@gnu.org
> Date: Sat, 30 Nov 2024 19:08:40 +0100
>
> > So I don't see how that move could damage the reputation of Texinfo.
>
> Emacs is extremely niche, while reading the documentation of various GNU
> packages is not. Ergo, we recommend people to read documentation using
> info (see e.g. help2man generated output) - as we should.
Actually, I believe most people read the HTML version of the Texinfo
documentation.
> > Do you have any information to suggest that many people use the
> > stand-alone reader?
>
> Do you have information to suggest that many people use the in-Emacs
> reader? I certainly do use it, so we can put that a mark on the
> chalkboard.
I think Emacs users use Emacs (of course), and the rest read the
manuals in their HTML format. I have yet to see a number of people
who use the stand-alone reader that cannot be counted on the fingers
of a single hand. (And don't misunderstand me: I think the
stand-alone Info reader is great, and personally invested quite a few
efforts in developing and porting it. My Windows port of Texinfo,
routinely available from the ezwinports site, is one of a couple,
perhaps even the only one, which includes a fully functional Windows
port of the stand-alone Info reader.)
Anyway, the initiative for moving info.info to Emacs was from the
Texinfo developers (I'm sure you can find the relevant discussions in
the archives). So if you think it should be moved back, feel free to
take it up with them.
^ permalink raw reply [flat|nested] 56+ messages in thread
* RE: [External] : Re: Proposal: Include C Manual from RMS in Emacs git, and/or release
2024-11-30 20:05 ` Eli Zaretskii
@ 2024-11-30 21:09 ` Drew Adams
2024-12-01 6:15 ` Eli Zaretskii
2024-12-01 9:53 ` Proposal: Include C Manual from RMS in Emacs git, and/or release Arsen Arsenović
2024-12-01 13:04 ` Johan Myréen
2 siblings, 1 reply; 56+ messages in thread
From: Drew Adams @ 2024-11-30 21:09 UTC (permalink / raw)
To: Eli Zaretskii, Arsen Arsenović
Cc: jb@jeremybryant.net, emacs-devel@gnu.org, rms@gnu.org
> Actually, I believe most people read the HTML
> version of the Texinfo documentation.
Interesting. Do you have some quantitative data
about the percentage of readings of HTML vs Info
by (non-Emacs) users?
I don't think otherwise - just wondering what
backs up your belief about this.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Proposal: Include C Manual from RMS in Emacs git, and/or release
2024-11-30 13:50 ` Eli Zaretskii
@ 2024-12-01 4:02 ` Sean Whitton
2024-12-01 7:45 ` Eli Zaretskii
2024-12-02 4:10 ` Proposal: Include C Manual from RMS in Emacs git, and/or release Richard Stallman
1 sibling, 1 reply; 56+ messages in thread
From: Sean Whitton @ 2024-12-01 4:02 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Jeremy Bryant, emacs-devel, rms
Hello,
On Sat 30 Nov 2024 at 03:50pm +02, Eli Zaretskii wrote:
> FWIW, I don't think this (IMO very useful and installed on my
> machines) manual belongs to Emacs. It should be a separate manual.
Could we add a pointer to it somewhere in our development notes? Maybe
CONTRIBUTE? This is the first I have heard of it.
--
Sean Whitton
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [External] : Re: Proposal: Include C Manual from RMS in Emacs git, and/or release
2024-11-30 21:09 ` [External] : " Drew Adams
@ 2024-12-01 6:15 ` Eli Zaretskii
2024-12-02 3:00 ` Texinfo reputation (was: Re: [External] : Re: Proposal: Include C Manual from RMS in Emacs git, and/or release) Max Nikulin
0 siblings, 1 reply; 56+ messages in thread
From: Eli Zaretskii @ 2024-12-01 6:15 UTC (permalink / raw)
To: Drew Adams; +Cc: arsen, jb, emacs-devel, rms
> From: Drew Adams <drew.adams@oracle.com>
> CC: "jb@jeremybryant.net" <jb@jeremybryant.net>,
> "emacs-devel@gnu.org"
> <emacs-devel@gnu.org>,
> "rms@gnu.org" <rms@gnu.org>
> Date: Sat, 30 Nov 2024 21:09:49 +0000
>
> > Actually, I believe most people read the HTML
> > version of the Texinfo documentation.
>
> Interesting. Do you have some quantitative data
> about the percentage of readings of HTML vs Info
> by (non-Emacs) users?
>
> I don't think otherwise - just wondering what
> backs up your belief about this.
My evidence is that when people report problems with GNU manuals, they
almost always show a URL of the HTML documentation.
Also, the number of bug reports about the stand-alone Info reader is
almost zero.
I don't have any other data, but I cannot think about any other way
people who don't use Emacs can read the documentation of GCC, GDB, GNU
Make, and other GNU tools.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Proposal: Include C Manual from RMS in Emacs git, and/or release
2024-12-01 4:02 ` Sean Whitton
@ 2024-12-01 7:45 ` Eli Zaretskii
2024-12-01 8:36 ` Sean Whitton
2024-12-05 5:05 ` Making the GNU C Manual easier to find in Info Richard Stallman
0 siblings, 2 replies; 56+ messages in thread
From: Eli Zaretskii @ 2024-12-01 7:45 UTC (permalink / raw)
To: Sean Whitton; +Cc: jb, emacs-devel, rms
> From: Sean Whitton <spwhitton@spwhitton.name>
> Cc: Jeremy Bryant <jb@jeremybryant.net>, emacs-devel@gnu.org, rms@gnu.org
> Date: Sun, 01 Dec 2024 12:02:58 +0800
>
> Hello,
>
> On Sat 30 Nov 2024 at 03:50pm +02, Eli Zaretskii wrote:
>
> > FWIW, I don't think this (IMO very useful and installed on my
> > machines) manual belongs to Emacs. It should be a separate manual.
>
> Could we add a pointer to it somewhere in our development notes? Maybe
> CONTRIBUTE? This is the first I have heard of it.
Isn't the fact that it was mentioned here enough to have it found by a
browser search?
There are a lot of useful manuals that people might not hear about,
but it doesn't mean it's Emacs's job to solve those problems.
How about taking this up with the Texinfo developers? After all,
Texinfo is a much more logical place to advertise GNU manuals, see
dir-example and htmlxref.cnf files in the Texinfo tree.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Proposal: Include C Manual from RMS in Emacs git, and/or release
2024-12-01 7:45 ` Eli Zaretskii
@ 2024-12-01 8:36 ` Sean Whitton
2024-12-01 10:01 ` Eli Zaretskii
2024-12-05 5:05 ` Making the GNU C Manual easier to find in Info Richard Stallman
1 sibling, 1 reply; 56+ messages in thread
From: Sean Whitton @ 2024-12-01 8:36 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: jb, emacs-devel, rms
Hello,
On Sun 01 Dec 2024 at 09:45am +02, Eli Zaretskii wrote:
>> From: Sean Whitton <spwhitton@spwhitton.name>
>> Cc: Jeremy Bryant <jb@jeremybryant.net>, emacs-devel@gnu.org, rms@gnu.org
>> Date: Sun, 01 Dec 2024 12:02:58 +0800
>>
>> Hello,
>>
>> On Sat 30 Nov 2024 at 03:50pm +02, Eli Zaretskii wrote:
>>
>> > FWIW, I don't think this (IMO very useful and installed on my
>> > machines) manual belongs to Emacs. It should be a separate manual.
>>
>> Could we add a pointer to it somewhere in our development notes? Maybe
>> CONTRIBUTE? This is the first I have heard of it.
>
> Isn't the fact that it was mentioned here enough to have it found by a
> browser search?
>
> There are a lot of useful manuals that people might not hear about,
> but it doesn't mean it's Emacs's job to solve those problems.
>
> How about taking this up with the Texinfo developers? After all,
> Texinfo is a much more logical place to advertise GNU manuals, see
> dir-example and htmlxref.cnf files in the Texinfo tree.
My thought is that it might be particularly helpful for people learning
more C for Emacs development, because it's written by Richard.
Some of the thinking behind the less usual ways in which C gets used for
Emacs might become clearer, perhaps?
Having not yet read the manual, my opinion counts for little.
--
Sean Whitton
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Proposal: Include C Manual from RMS in Emacs git, and/or release
2024-11-30 20:05 ` Eli Zaretskii
2024-11-30 21:09 ` [External] : " Drew Adams
@ 2024-12-01 9:53 ` Arsen Arsenović
2024-12-01 10:12 ` Eli Zaretskii
2024-12-01 13:04 ` Johan Myréen
2 siblings, 1 reply; 56+ messages in thread
From: Arsen Arsenović @ 2024-12-01 9:53 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: jb, emacs-devel, rms
[-- Attachment #1: Type: text/plain, Size: 3641 bytes --]
Hi Eli,
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Arsen Arsenović <arsen@aarsen.me>
>> Cc: jb@jeremybryant.net, emacs-devel@gnu.org, rms@gnu.org
>> Date: Sat, 30 Nov 2024 19:08:40 +0100
>>
>> > So I don't see how that move could damage the reputation of Texinfo.
>>
>> Emacs is extremely niche, while reading the documentation of various GNU
>> packages is not. Ergo, we recommend people to read documentation using
>> info (see e.g. help2man generated output) - as we should.
>
> Actually, I believe most people read the HTML version of the Texinfo
> documentation.
Yes, fair enough, that is likely overall most popular, but I still don't
doubt 'info' is more widespread than Emacs.
>> > Do you have any information to suggest that many people use the
>> > stand-alone reader?
>>
>> Do you have information to suggest that many people use the in-Emacs
>> reader? I certainly do use it, so we can put that a mark on the
>> chalkboard.
>
> I think Emacs users use Emacs (of course), and the rest read the
> manuals in their HTML format. I have yet to see a number of people
> who use the stand-alone reader that cannot be counted on the fingers
> of a single hand. (And don't misunderstand me: I think the
> stand-alone Info reader is great, and personally invested quite a few
> efforts in developing and porting it. My Windows port of Texinfo,
> routinely available from the ezwinports site, is one of a couple,
> perhaps even the only one, which includes a fully functional Windows
> port of the stand-alone Info reader.)
Even those that do use the HTML format might sometimes not be able to
conveniently access it (e.g. on a remote machine, or because distros
don't install HTML versions of texinfo documentation).
Also, the HTML format is harder to browse (no convenient index
searching, for instance) currently. There was a proposed JS-based
enhancement for this interface,[1](archive: [2]), developing that could
remedy this (as long as it implemented graceful degradation so that it
can be viewed without JS).
FTR I do hope that we manage to get a 'properly integrated', 'dir' node
and all, index-searchable, ... installed HTML version of Texinfo
documentation in GNU packages and GNU distributions. I think the info
file format has some drawbacks (e.g. it's a catfile-style format, with
hard wrapping, which fails on narrow screens of course). I wonder
whether Emacs could read (the relevant parts of) that HTML.
If not, then maybe a new more Emacs-friendly format to replace the
current info file format is needed.
> Anyway, the initiative for moving info.info to Emacs was from the
> Texinfo developers (I'm sure you can find the relevant discussions in
> the archives). So if you think it should be moved back, feel free to
> take it up with them.
Yes, I've exchanged mail with Gavin about this before. I was using
info.info as an example of problems caused by packaging up unrelated
things together in this thread.
In hindsight, I'd also not mind if info-stnd.texi contained a copy of
the Info tutorial that the Emacs info manual includes, so that the
standalone viewers get-info-help-node works always. What do you think
of that?
If that was to be the case, info-stnd would not need to rely on
info.info (at least for any reason I can think of), and so, this would
become a non-issue.
Have a lovely day.
[1] https://www.gnu.org/software/texinfo/manual/texinfo-html/index.html
[2] https://web.archive.org/web/20190407054314/https://www.gnu.org/software/texinfo/manual/texinfo-html/index.html
--
Arsen Arsenović
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Proposal: Include C Manual from RMS in Emacs git, and/or release
2024-12-01 8:36 ` Sean Whitton
@ 2024-12-01 10:01 ` Eli Zaretskii
2024-12-01 11:13 ` Sean Whitton
0 siblings, 1 reply; 56+ messages in thread
From: Eli Zaretskii @ 2024-12-01 10:01 UTC (permalink / raw)
To: Sean Whitton; +Cc: jb, emacs-devel, rms
> From: Sean Whitton <spwhitton@spwhitton.name>
> Cc: jb@jeremybryant.net, emacs-devel@gnu.org, rms@gnu.org
> Date: Sun, 01 Dec 2024 16:36:02 +0800
>
> On Sun 01 Dec 2024 at 09:45am +02, Eli Zaretskii wrote:
>
> >> From: Sean Whitton <spwhitton@spwhitton.name>
> >> Cc: Jeremy Bryant <jb@jeremybryant.net>, emacs-devel@gnu.org, rms@gnu.org
> >> Date: Sun, 01 Dec 2024 12:02:58 +0800
> >>
> >> Hello,
> >>
> >> On Sat 30 Nov 2024 at 03:50pm +02, Eli Zaretskii wrote:
> >>
> >> > FWIW, I don't think this (IMO very useful and installed on my
> >> > machines) manual belongs to Emacs. It should be a separate manual.
> >>
> >> Could we add a pointer to it somewhere in our development notes? Maybe
> >> CONTRIBUTE? This is the first I have heard of it.
> >
> > Isn't the fact that it was mentioned here enough to have it found by a
> > browser search?
> >
> > There are a lot of useful manuals that people might not hear about,
> > but it doesn't mean it's Emacs's job to solve those problems.
> >
> > How about taking this up with the Texinfo developers? After all,
> > Texinfo is a much more logical place to advertise GNU manuals, see
> > dir-example and htmlxref.cnf files in the Texinfo tree.
>
> My thought is that it might be particularly helpful for people learning
> more C for Emacs development, because it's written by Richard.
> Some of the thinking behind the less usual ways in which C gets used for
> Emacs might become clearer, perhaps?
>
> Having not yet read the manual, my opinion counts for little.
Then maybe let's talk again after you have read that manual?
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Proposal: Include C Manual from RMS in Emacs git, and/or release
2024-12-01 9:53 ` Proposal: Include C Manual from RMS in Emacs git, and/or release Arsen Arsenović
@ 2024-12-01 10:12 ` Eli Zaretskii
2024-12-01 10:54 ` Arsen Arsenović
0 siblings, 1 reply; 56+ messages in thread
From: Eli Zaretskii @ 2024-12-01 10:12 UTC (permalink / raw)
To: Arsen Arsenović; +Cc: jb, emacs-devel, rms
> From: Arsen Arsenović <arsen@aarsen.me>
> Cc: jb@jeremybryant.net, emacs-devel@gnu.org, rms@gnu.org
> Date: Sun, 01 Dec 2024 10:53:20 +0100
>
> > Anyway, the initiative for moving info.info to Emacs was from the
> > Texinfo developers (I'm sure you can find the relevant discussions in
> > the archives). So if you think it should be moved back, feel free to
> > take it up with them.
>
> Yes, I've exchanged mail with Gavin about this before. I was using
> info.info as an example of problems caused by packaging up unrelated
> things together in this thread.
>
> In hindsight, I'd also not mind if info-stnd.texi contained a copy of
> the Info tutorial that the Emacs info manual includes, so that the
> standalone viewers get-info-help-node works always. What do you think
> of that?
Someone will have to do the job, and the non-traditional structure of
info.info makes that a tad harder.
There's also an additional problem for Emacs users: if info.info is
not in Emacs, then new users of Info have no way of learning to use
Info. So I guess this will have to be some kind of duplication or
something?
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Proposal: Include C Manual from RMS in Emacs git, and/or release
2024-12-01 10:12 ` Eli Zaretskii
@ 2024-12-01 10:54 ` Arsen Arsenović
0 siblings, 0 replies; 56+ messages in thread
From: Arsen Arsenović @ 2024-12-01 10:54 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: jb, emacs-devel, rms
[-- Attachment #1: Type: text/plain, Size: 1433 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
>> In hindsight, I'd also not mind if info-stnd.texi contained a copy of
>> the Info tutorial that the Emacs info manual includes, so that the
>> standalone viewers get-info-help-node works always. What do you think
>> of that?
>
> Someone will have to do the job, and the non-traditional structure of
> info.info makes that a tad harder.
>
> There's also an additional problem for Emacs users: if info.info is
> not in Emacs, then new users of Info have no way of learning to use
> Info. So I guess this will have to be some kind of duplication or
> something?
Hm, yes, I had taken it for granted that Texinfo is installed if Emacs
is, but that might not be true. That makes duplicating the tutorial bit
of info.info into info-stnd more appealing, I think.
My thinking was to break out the (info)Getting Started node and its
subnodes into info-tutorial.texi or such, and @include it into both
manuals. There would need to be slight adjustment to the text, as not
all of the first paragraph is applicable to info-stnd.
Quickly skimming it, that node list appears to be closed under internal
(in the sense of "within the same manual") referencing, except for a
reference to *note Emacs Info Variables::, but that could be made
conditionally included or a conditionally external reference.
I think it's doable with fairly little cost.
--
Arsen Arsenović
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Proposal: Include C Manual from RMS in Emacs git, and/or release
2024-12-01 10:01 ` Eli Zaretskii
@ 2024-12-01 11:13 ` Sean Whitton
0 siblings, 0 replies; 56+ messages in thread
From: Sean Whitton @ 2024-12-01 11:13 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: jb, emacs-devel, rms
Hello,
On Sun 01 Dec 2024 at 12:01pm +02, Eli Zaretskii wrote:
> Then maybe let's talk again after you have read that manual?
Yes, very fair!
--
Sean Whitton
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Proposal: Include C Manual from RMS in Emacs git, and/or release
2024-11-30 20:05 ` Eli Zaretskii
2024-11-30 21:09 ` [External] : " Drew Adams
2024-12-01 9:53 ` Proposal: Include C Manual from RMS in Emacs git, and/or release Arsen Arsenović
@ 2024-12-01 13:04 ` Johan Myréen
2024-12-04 6:09 ` Richard Stallman
2 siblings, 1 reply; 56+ messages in thread
From: Johan Myréen @ 2024-12-01 13:04 UTC (permalink / raw)
To: Eli Zaretskii, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 2098 bytes --]
One data point. From the Arch Linux Wiki (
https://wiki.archlinux.org/title/GNU):
While most GNU software also provides man pages
> <https://wiki.archlinux.org/title/Man_page>, the Info documents tend to
> be more comprehensive. To view an Info document, simply enter:
$ info
*page_name*
Admittedly, Arch Linux is a niche Linux distribution.
On Sat, 30 Nov 2024 at 22:06, Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Arsen Arsenović <arsen@aarsen.me>
> > Cc: jb@jeremybryant.net, emacs-devel@gnu.org, rms@gnu.org
> > Date: Sat, 30 Nov 2024 19:08:40 +0100
> >
> > > So I don't see how that move could damage the reputation of Texinfo.
> >
> > Emacs is extremely niche, while reading the documentation of various GNU
> > packages is not. Ergo, we recommend people to read documentation using
> > info (see e.g. help2man generated output) - as we should.
>
> Actually, I believe most people read the HTML version of the Texinfo
> documentation.
>
> > > Do you have any information to suggest that many people use the
> > > stand-alone reader?
> >
> > Do you have information to suggest that many people use the in-Emacs
> > reader? I certainly do use it, so we can put that a mark on the
> > chalkboard.
>
> I think Emacs users use Emacs (of course), and the rest read the
> manuals in their HTML format. I have yet to see a number of people
> who use the stand-alone reader that cannot be counted on the fingers
> of a single hand. (And don't misunderstand me: I think the
> stand-alone Info reader is great, and personally invested quite a few
> efforts in developing and porting it. My Windows port of Texinfo,
> routinely available from the ezwinports site, is one of a couple,
> perhaps even the only one, which includes a fully functional Windows
> port of the stand-alone Info reader.)
>
> Anyway, the initiative for moving info.info to Emacs was from the
> Texinfo developers (I'm sure you can find the relevant discussions in
> the archives). So if you think it should be moved back, feel free to
> take it up with them.
>
>
[-- Attachment #2: Type: text/html, Size: 3184 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Texinfo reputation (was: Re: [External] : Re: Proposal: Include C Manual from RMS in Emacs git, and/or release)
2024-12-01 6:15 ` Eli Zaretskii
@ 2024-12-02 3:00 ` Max Nikulin
2024-12-02 12:47 ` Eli Zaretskii
2024-12-03 18:51 ` Dr. Arne Babenhauserheide
0 siblings, 2 replies; 56+ messages in thread
From: Max Nikulin @ 2024-12-02 3:00 UTC (permalink / raw)
To: emacs-devel
On 01/12/2024 13:15, Eli Zaretskii wrote:
> My evidence is that when people report problems with GNU manuals, they
> almost always show a URL of the HTML documentation.
I would include an http(s): link into an issue report to avoid ugly
multistep style of addressing info nodes as in
> emacs --help
[...]
> Run M-x info RET m emacs RET m emacs invocation RET inside Emacs to
> read the main documentation for these command-line arguments.
and to allow people reading the message from a mobile device to easily
inspect the actual text. That is why I consider URLs in reports as a
weak evidence. Side note: likely I would duplicate the reference as
(info "(emacs) Emacs Invocation").
My impression based on debian-user mailing list messages is that people
avoid info manuals due to inconvenience of the standalone reader. They
have some workarounds for cases when length of a man page is excessively
high for comfortable reading. An example is PDF generated from BASH man
page despite BASH has the manual in the texinfo format.
Those who read .info documents may recommend e.g. pinfo. From my point
of view, tkinfo is usually better than "info".
Another issue is that there is no standard way to share a link to a
specific node of a texinfo document. khelpcenter and yelp use different
URL schemes for this purpose. It may not be easy to get link to the
currently displayed node and that style of links would not be helpful
for Emacs or standalone info browsers.
Debian 12 bookworm: "emacs -f info-standalone" option is not included into
update-alternatives --list infobrowser
/usr/bin/info
/usr/bin/tkinfo
Feel free to forward this message to a texinfo mailing list. Another
reason why I have decided to post it here is the following message:
On 30/11/2024 21:12, Eli Zaretskii wrote:
> Texinfo comes with info-stnd.info,
> which documents the stand-alone reader, which is part of Texinfo.
>
> So I don't see how that move could damage the reputation of Texinfo.
>
> Do you have any information to suggest that many people use the
> stand-alone reader?
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Proposal: Include C Manual from RMS in Emacs git, and/or release
2024-11-30 13:50 ` Eli Zaretskii
2024-12-01 4:02 ` Sean Whitton
@ 2024-12-02 4:10 ` Richard Stallman
2024-12-02 12:57 ` Eli Zaretskii
2024-12-03 20:07 ` Björn Bidar
1 sibling, 2 replies; 56+ messages in thread
From: Richard Stallman @ 2024-12-02 4:10 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: jb, emacs-devel
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> FWIW, I don't think this (IMO very useful and installed on my
> machines) manual belongs to Emacs. It should be a separate manual.
As a general design principle, it doesn't seem to make sense to
include all GNU manuals in the Emacs distribution merely because they
are useful manuals. The idea was to relese them separately and have
them installed separately into a combined info tree.
Why is that not working? What needs to be changed in some GNU/Linux
distros?
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Texinfo reputation (was: Re: [External] : Re: Proposal: Include C Manual from RMS in Emacs git, and/or release)
2024-12-02 3:00 ` Texinfo reputation (was: Re: [External] : Re: Proposal: Include C Manual from RMS in Emacs git, and/or release) Max Nikulin
@ 2024-12-02 12:47 ` Eli Zaretskii
2024-12-03 2:51 ` Texinfo reputation Max Nikulin
2024-12-03 18:51 ` Dr. Arne Babenhauserheide
1 sibling, 1 reply; 56+ messages in thread
From: Eli Zaretskii @ 2024-12-02 12:47 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-devel
> From: Max Nikulin <manikulin@gmail.com>
> Date: Mon, 2 Dec 2024 10:00:56 +0700
>
> Those who read .info documents may recommend e.g. pinfo. From my point
> of view, tkinfo is usually better than "info".
Are they being developed? ISTR that someone said they were no longer
updated.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Proposal: Include C Manual from RMS in Emacs git, and/or release
2024-12-02 4:10 ` Proposal: Include C Manual from RMS in Emacs git, and/or release Richard Stallman
@ 2024-12-02 12:57 ` Eli Zaretskii
2024-12-03 23:03 ` [ELPA] New package c-intro-and-ref -- was " Jeremy Bryant
2024-12-05 5:05 ` Richard Stallman
2024-12-03 20:07 ` Björn Bidar
1 sibling, 2 replies; 56+ messages in thread
From: Eli Zaretskii @ 2024-12-02 12:57 UTC (permalink / raw)
To: rms; +Cc: jb, emacs-devel
> From: Richard Stallman <rms@gnu.org>
> Cc: jb@jeremybryant.net, emacs-devel@gnu.org
> Date: Sun, 01 Dec 2024 23:10:09 -0500
>
> > FWIW, I don't think this (IMO very useful and installed on my
> > machines) manual belongs to Emacs. It should be a separate manual.
>
> As a general design principle, it doesn't seem to make sense to
> include all GNU manuals in the Emacs distribution merely because they
> are useful manuals. The idea was to relese them separately and have
> them installed separately into a combined info tree.
>
> Why is that not working? What needs to be changed in some GNU/Linux
> distros?
It does work in general. However, some manuals, which don't belong to
any project in particular, are largely unknown to exist. The two
prominent examples I have are for some reason both related to the C
language: gnu-c-manual.info and c.info. The latter is not even
mentioned in dir-example file that the Texinfo project distributes.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Texinfo reputation
2024-12-02 12:47 ` Eli Zaretskii
@ 2024-12-03 2:51 ` Max Nikulin
2024-12-03 12:38 ` Eli Zaretskii
0 siblings, 1 reply; 56+ messages in thread
From: Max Nikulin @ 2024-12-03 2:51 UTC (permalink / raw)
To: emacs-devel
On 02/12/2024 19:47, Eli Zaretskii wrote:
>> From: Max Nikulin Mon, 2 Dec 2024 10:00:56 +0700
>>
>> Those who read .info documents may recommend e.g. pinfo. From my point
>> of view, tkinfo is usually better than "info".
>
> Are they being developed? ISTR that someone said they were no longer
> updated.
I have not tried to report bugs for tkinfo (it hangs sometimes on search
attempts, but I am unaware of really serious issues). It has some
advantages and disadvantages in comparison to other means of reading
texinfo documents. It is not perfect, but in some sense it is feature
complete. I am grateful to its developers and maintainers. It is
available in Debian:
<https://tracker.debian.org/pkg/tkinfo>
I was not inspired by pinfo description, so I have not tried it. It has
some issue with maintenance and it has been kicked out of Debian
testing. It is still available in current stable (bookworm):
<https://tracker.debian.org/pkg/pinfo>
In my opinion, it means that texinfo docs in general and .info format in
particular are becoming less useful outside of Emacs. Formatting of PDF
is too rigid. HTML files are either excessively huge or uncomfortably
granular with enough nodes containing just a handful lines of text.
Moreover, there is a fraction of users who prefers locally installed
documents.
A container format like EPUB might be an option for distributing
formatted documents, but the issue is decent free viewers for various
platforms. It seems they must be based on almost full fledged web
browser engines.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Texinfo reputation
2024-12-03 2:51 ` Texinfo reputation Max Nikulin
@ 2024-12-03 12:38 ` Eli Zaretskii
0 siblings, 0 replies; 56+ messages in thread
From: Eli Zaretskii @ 2024-12-03 12:38 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-devel
> From: Max Nikulin <manikulin@gmail.com>
> Date: Tue, 3 Dec 2024 09:51:49 +0700
>
> On 02/12/2024 19:47, Eli Zaretskii wrote:
> >> From: Max Nikulin Mon, 2 Dec 2024 10:00:56 +0700
> >>
> >> Those who read .info documents may recommend e.g. pinfo. From my point
> >> of view, tkinfo is usually better than "info".
> >
> > Are they being developed? ISTR that someone said they were no longer
> > updated.
>
> I have not tried to report bugs for tkinfo (it hangs sometimes on search
> attempts, but I am unaware of really serious issues). It has some
> advantages and disadvantages in comparison to other means of reading
> texinfo documents. It is not perfect, but in some sense it is feature
> complete. I am grateful to its developers and maintainers. It is
> available in Debian:
> <https://tracker.debian.org/pkg/tkinfo>
>
> I was not inspired by pinfo description, so I have not tried it. It has
> some issue with maintenance and it has been kicked out of Debian
> testing. It is still available in current stable (bookworm):
> <https://tracker.debian.org/pkg/pinfo>
>
> In my opinion, it means that texinfo docs in general and .info format in
> particular are becoming less useful outside of Emacs.
That was the conclusion in that discussion some years ago where it was
decided to move info.info to Emacs.
> Formatting of PDF
> is too rigid. HTML files are either excessively huge or uncomfortably
> granular with enough nodes containing just a handful lines of text.
> Moreover, there is a fraction of users who prefers locally installed
> documents.
IME, many users report issues with documentation using HTML and PDF
references. HTML can also be installed locally.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Texinfo reputation
2024-12-02 3:00 ` Texinfo reputation (was: Re: [External] : Re: Proposal: Include C Manual from RMS in Emacs git, and/or release) Max Nikulin
2024-12-02 12:47 ` Eli Zaretskii
@ 2024-12-03 18:51 ` Dr. Arne Babenhauserheide
2024-12-05 4:56 ` Max Nikulin
1 sibling, 1 reply; 56+ messages in thread
From: Dr. Arne Babenhauserheide @ 2024-12-03 18:51 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1388 bytes --]
Max Nikulin <manikulin@gmail.com> writes:
> My impression based on debian-user mailing list messages is that
> people avoid info manuals due to inconvenience of the standalone
> reader. They have some workarounds for cases when length of a man page
> is excessively high for comfortable reading. An example is PDF
> generated from BASH man page despite BASH has the manual in the
> texinfo format.
I used to be annoyed by the standalone reader, but with
info --usage <package>
it’s actually pretty good. It nowadays also gives a useful answer when
looking for a non-existing manual:
info NOTEXISTING
info: No menu item 'NOTEXISTING' in node '(dir)Top'
That was my main gripe with it, and I guess that most old timers don’t
know about that change.
You even get very fast full-text search through the manuals.
What I just found a bit lacking is tool support: pygments does not have
highlighting for texinfo (latex export of texinfo sources), export to
HTML doesn’t look great by default.
And: info --usage git does not give the invocation page — because that
node is missing in the manual. That’s not a problem of texinfo, but an
indication that something may be missing:
Is there a linter for texinfo that remarks such problems?
Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Proposal: Include C Manual from RMS in Emacs git, and/or release
2024-12-02 4:10 ` Proposal: Include C Manual from RMS in Emacs git, and/or release Richard Stallman
2024-12-02 12:57 ` Eli Zaretskii
@ 2024-12-03 20:07 ` Björn Bidar
1 sibling, 0 replies; 56+ messages in thread
From: Björn Bidar @ 2024-12-03 20:07 UTC (permalink / raw)
To: Richard Stallman; +Cc: Eli Zaretskii, jb, emacs-devel
Richard Stallman <rms@gnu.org> writes:
> [[[ To any NSA and FBI agents reading my email: please consider ]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> > FWIW, I don't think this (IMO very useful and installed on my
> > machines) manual belongs to Emacs. It should be a separate manual.
>
> As a general design principle, it doesn't seem to make sense to
> include all GNU manuals in the Emacs distribution merely because they
> are useful manuals. The idea was to relese them separately and have
> them installed separately into a combined info tree.
>
> Why is that not working? What needs to be changed in some GNU/Linux
> distros?
The issues the others mentioned mainly the lack of acceptance of the
format and for sometime the possibility to find info manual manly due
the first problem.
Some projects switched to documentation systems which don't provide
anything but HTML or PDF such as e.g. Doxygen or those where the info
output is available but fragile and usually not enabled due problem one.
In the instance of the this specific manual it's just that it's one
specific document which isn't distributed along other software which is
unusual but also that it doesn't get much exposure I think.
The last issue is that the license make it impossible to be distributed
for some namely those which are Debian based but not solely those.
Related: I package the manual for RPM based distribution below:
https://build.opensuse.org/package/show/home:Thaodan:Documentation/c-intro-and-ref
I will submit the manual to openSUSE unless some other issue comes up.
^ permalink raw reply [flat|nested] 56+ messages in thread
* [ELPA] New package c-intro-and-ref -- was Re: Proposal: Include C Manual from RMS in Emacs git, and/or release
2024-12-02 12:57 ` Eli Zaretskii
@ 2024-12-03 23:03 ` Jeremy Bryant
2024-12-04 12:33 ` Eli Zaretskii
2024-12-04 20:02 ` Suhail Singh
2024-12-05 5:05 ` Richard Stallman
1 sibling, 2 replies; 56+ messages in thread
From: Jeremy Bryant @ 2024-12-03 23:03 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: rms, emacs-devel, Philip Kaludercic
[-- Attachment #1: Type: text/plain, Size: 1704 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Richard Stallman <rms@gnu.org>
>> Cc: jb@jeremybryant.net, emacs-devel@gnu.org
>> Date: Sun, 01 Dec 2024 23:10:09 -0500
>>
>> > FWIW, I don't think this (IMO very useful and installed on my
>> > machines) manual belongs to Emacs. It should be a separate manual.
>>
>> As a general design principle, it doesn't seem to make sense to
>> include all GNU manuals in the Emacs distribution merely because they
>> are useful manuals. The idea was to relese them separately and have
>> them installed separately into a combined info tree.
>>
>> Why is that not working? What needs to be changed in some GNU/Linux
>> distros?
>
> It does work in general. However, some manuals, which don't belong to
> any project in particular, are largely unknown to exist. The two
> prominent examples I have are for some reason both related to the C
> language: gnu-c-manual.info and c.info. The latter is not even
> mentioned in dir-example file that the Texinfo project distributes.
Understood.
I have created a prototype ELPA package, comments welcome?
upstream url:
https://github.com/jeremy-bryant/c-intro-and-ref
As some manuals are available in GNU/Linux distros but not this one, it would provide a distribution mechanism for c.info
I also include a PDF output.
Current Package name, proposed for ELPA: c-intro-and-ref
This matches the existing manual distribution.
Perhaps a name such as: gnu-c-manual
would be easier to find, however on gnu.org this points to another,
maybe a predecessor manual. (https://www.gnu.org/software/gnu-c-manual/gnu-c-manual.html)
Main file: c-intro-and-ref.el
This is simply a placeholder for the c.texi and other files
[-- Attachment #2: c-intro-and-ref.el --]
[-- Type: application/emacs-lisp, Size: 2838 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Proposal: Include C Manual from RMS in Emacs git, and/or release
2024-12-01 13:04 ` Johan Myréen
@ 2024-12-04 6:09 ` Richard Stallman
0 siblings, 0 replies; 56+ messages in thread
From: Richard Stallman @ 2024-12-04 6:09 UTC (permalink / raw)
To: Johan Myréen; +Cc: eliz, emacs-devel
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
We want to support Info format and HTML for reading Info files,
and we want to provide good software for reading both.
We want all GNU/Linux distros to provide both formats and make them
easy and convenient to read.
Please let's focus on advancing these goals, not on arguing which is
of them is better than which.
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [ELPA] New package c-intro-and-ref -- was Re: Proposal: Include C Manual from RMS in Emacs git, and/or release
2024-12-03 23:03 ` [ELPA] New package c-intro-and-ref -- was " Jeremy Bryant
@ 2024-12-04 12:33 ` Eli Zaretskii
2024-12-04 22:58 ` Jeremy Bryant
` (2 more replies)
2024-12-04 20:02 ` Suhail Singh
1 sibling, 3 replies; 56+ messages in thread
From: Eli Zaretskii @ 2024-12-04 12:33 UTC (permalink / raw)
To: Jeremy Bryant; +Cc: rms, emacs-devel, philipk, Stefan Monnier
> From: Jeremy Bryant <jb@jeremybryant.net>
> Cc: rms@gnu.org, emacs-devel@gnu.org, Philip Kaludercic <philipk@posteo.net>
> Date: Tue, 03 Dec 2024 23:03:42 +0000
>
> I have created a prototype ELPA package, comments welcome?
Are we providing packages that include only Info manuals, which
document stuff that is not specific to Emacs? Because I don't see how
it would be a good idea to have this as an ELPA package.
But if we do accept such packages on ELPA, then I have 2 additional
similar suggestions:
. Git manual in Info format
. Python 3 manual in Info format
> Current Package name, proposed for ELPA: c-intro-and-ref
> This matches the existing manual distribution.
> Perhaps a name such as: gnu-c-manual
That'd be wrong, since this manual doesn't describe GNU C, it
describes the C language in general. (There's a separate GNU C
manual, btw.)
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [ELPA] New package c-intro-and-ref -- was Re: Proposal: Include C Manual from RMS in Emacs git, and/or release
2024-12-03 23:03 ` [ELPA] New package c-intro-and-ref -- was " Jeremy Bryant
2024-12-04 12:33 ` Eli Zaretskii
@ 2024-12-04 20:02 ` Suhail Singh
[not found] ` <87wmgf9h70.fsf@jeremybryant.net>
1 sibling, 1 reply; 56+ messages in thread
From: Suhail Singh @ 2024-12-04 20:02 UTC (permalink / raw)
To: Jeremy Bryant; +Cc: Eli Zaretskii, rms, emacs-devel, Philip Kaludercic
Jeremy Bryant <jb@jeremybryant.net> writes:
> I have created a prototype ELPA package, comments welcome?
>
> upstream url:
> https://github.com/jeremy-bryant/c-intro-and-ref
>
> ...
>
> Main file: c-intro-and-ref.el
> This is simply a placeholder for the c.texi and other files
Thank you for packaging this in a repository to make it easily
accessible via package-vc-install.
It would help if the name of the texinfo file was the same as that of
the package. Currently, when using package-vc-install, the name of the
checkout directory has to be specified as 'c (i.e., matching the name of
the texinfo file, as opposed to the repository), since that name is used
by package-vc when generating the info output from the texinfo source.
--
Suhail
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [ELPA] New package c-intro-and-ref -- was Re: Proposal: Include C Manual from RMS in Emacs git, and/or release
2024-12-04 12:33 ` Eli Zaretskii
@ 2024-12-04 22:58 ` Jeremy Bryant
2024-12-05 5:45 ` Eli Zaretskii
2024-12-05 5:03 ` Max Nikulin
2024-12-05 18:47 ` Philip Kaludercic
2 siblings, 1 reply; 56+ messages in thread
From: Jeremy Bryant @ 2024-12-04 22:58 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: rms, emacs-devel, philipk, Stefan Monnier
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Jeremy Bryant <jb@jeremybryant.net>
>> Cc: rms@gnu.org, emacs-devel@gnu.org, Philip Kaludercic
>> <philipk@posteo.net>
>> Date: Tue, 03 Dec 2024 23:03:42 +0000
>>
>> I have created a prototype ELPA package, comments welcome?
>
> Are we providing packages that include only Info manuals, which
> document stuff that is not specific to Emacs? Because I don't see how
> it would be a good idea to have this as an ELPA package.
I hear that maybe it's not a good idea, as this is not Emacs specific.
From a complementary point of view, reading this list it appears that
there is a smaller number of C contributors to Emacs, compared to Lisp,
and more C contributors are needed to work on Emacs.
Can we facilitate C documentation?
For example. The info-look.el subsystem already adds lookup facility for manuals such
as (libc). Wouldn't it be useful to also have c.info similarly
available and to aid in Emacs C development? That is
part of the motivation.
>
> But if we do accept such packages on ELPA, then I have 2 additional
> similar suggestions:
>
> . Git manual in Info format
> . Python 3 manual in Info format
Yes, I recently wrote about the second point for Python, so I would agree.
(https://onlisp.co.uk/Creating-an-info-manual-for-Python.html)
I may be able to volunteer towards a prototype, depending on time.
>
>> Current Package name, proposed for ELPA: c-intro-and-ref
>> This matches the existing manual distribution.
>> Perhaps a name such as: gnu-c-manual
>
> That'd be wrong, since this manual doesn't describe GNU C, it
> describes the C language in general. (There's a separate GNU C
> manual, btw.)
Thanks for the perspective, I do find the several names overlapping,
possibly for historical reasons.
The c.texi file starts with a mention of GNU C
@direntry
* C: (c). GNU C Language Intro and Reference Manual
@end direntry
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [ELPA] New package c-intro-and-ref -- was Re: Proposal: Include C Manual from RMS in Emacs git, and/or release
[not found] ` <87wmgf9h70.fsf@jeremybryant.net>
@ 2024-12-04 23:52 ` Suhail Singh
0 siblings, 0 replies; 56+ messages in thread
From: Suhail Singh @ 2024-12-04 23:52 UTC (permalink / raw)
To: Jeremy Bryant; +Cc: Suhail Singh, Emacs-devel mailing list
Jeremy Bryant <jb@jeremybryant.net> writes:
>>> Main file: c-intro-and-ref.el
>>> This is simply a placeholder for the c.texi and other files
>>
>> Thank you for packaging this in a repository to make it easily
>> accessible via package-vc-install.
>>
>> It would help if the name of the texinfo file was the same as that of
>> the package. Currently, when using package-vc-install, the name of the
>> checkout directory has to be specified as 'c (i.e., matching the name of
>> the texinfo file, as opposed to the repository), since that name is used
>> by package-vc when generating the info output from the texinfo source.
>
> The manual example ((emacs) Fetching Package Sources)
> seems to allow a :doc keyword?
This isn't about the :doc keyword. It's a matter of consistency (or
inconsistency). I shall leave it up to you and others to decide whether
the desire for consistency is foolish in this instance.
As things currently stand, one needs to do something like the below:
#+begin_src emacs-lisp
(package-vc-install
'(c :url "https://github.com/jeremy-bryant/c-intro-and-ref"
:branch "master"
:rev :newest
:doc "./c.texi"))
#+end_src
Note, that while the name of the package is c-intro-and-ref, one needs
to provide the name "c" (i.e., that which matches the texinfo source) in
order for things to work.
The above clones the repository within ~/.emacs.d/elpa/c and compiles
the texinfo source to ~/.emacs.d/elpa/c/c.info.
If one is using use-package along with vc-use-package, the above
translates to:
#+begin_src emacs-lisp
(use-package c-intro-and-ref :ensure nil
:vc (c :url "https://github.com/jeremy-bryant/c-intro-and-ref"
:branch "master"
:rev :newest
:doc "./c.texi"))
#+end_src
And in this form the inconsistency between the name being used by
use-package vs the name being used by package-vc-install becomes a
little more apparent. Since the name given to package-vc-install
determines the name of the generated info file (as opposed to the name
of the texinfo source), this isn't optional. The result is that the
phantom library "c-intro-and-ref" has to reside in ~/.emacs.d/elpa/c as
opposed to ~/.emacs.d/elpa/c-intro-and-ref.
If the file were instead named "c-intro-and-ref.texi", one could use
something like the below:
#+begin_src emacs-lisp
(use-package c-intro-and-ref :ensure nil
:vc (c-intro-and-ref :url "https://github.com/jeremy-bryant/c-intro-and-ref"
:branch "master"
:rev :newest
:doc "./c-intro-and-ref.texi"))
#+end_src
--
Suhail
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Texinfo reputation
2024-12-03 18:51 ` Dr. Arne Babenhauserheide
@ 2024-12-05 4:56 ` Max Nikulin
2024-12-05 7:45 ` Dr. Arne Babenhauserheide
0 siblings, 1 reply; 56+ messages in thread
From: Max Nikulin @ 2024-12-05 4:56 UTC (permalink / raw)
To: emacs-devel
On 04/12/2024 01:51, Dr. Arne Babenhauserheide wrote:
> Max Nikulin writes:
> I used to be annoyed by the standalone reader, but with
>
> info --usage <package>
>
> it’s actually pretty good.
Certainly it is more convenient, but a more universal link is still
or available locally via: info '(coreutils) ls invocation'
> It nowadays also gives a useful answer when
> looking for a non-existing manual:
>
> info NOTEXISTING
> info: No menu item 'NOTEXISTING' in node '(dir)Top'
I prefer this behavior as well. It reminds me another recent thread
however. "info git" renders the man page in my case. In the absence of
apparent banner, it requires some cognitive efforts to recognize that
the rendered document is not an info page. Citations in the following
message gives a fair summary of that discussion
<https://lists.debian.org/msgid-search/Z0dZjysfE3HE2nJZ@tuxteam.de>
debian-user. Re: help, man, etc. (was Re: Using terminal commands -
corner cases) Wed, 27 Nov 2024 18:40:31 +0100
> You even get very fast full-text search through the manuals.
I do not mind, but the real annoyance for new users is that key bindings
do not match e.g. "less" ones for next match. Mouse support in tkinfo
makes its usage significantly more intuitive.
> And: info --usage git does not give the invocation page — because that
> node is missing in the manual. That’s not a problem of texinfo, but an
> indication that something may be missing:
>
> Is there a linter for texinfo that remarks such problems?
Perhaps it is possible to write TeX code that spits a warning/error at
the end of the document when the "invocation" node is missed.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [ELPA] New package c-intro-and-ref -- was Re: Proposal: Include C Manual from RMS in Emacs git, and/or release
2024-12-04 12:33 ` Eli Zaretskii
2024-12-04 22:58 ` Jeremy Bryant
@ 2024-12-05 5:03 ` Max Nikulin
2024-12-05 18:47 ` Philip Kaludercic
2 siblings, 0 replies; 56+ messages in thread
From: Max Nikulin @ 2024-12-05 5:03 UTC (permalink / raw)
To: emacs-devel
On 04/12/2024 19:33, Eli Zaretskii wrote:
> Are we providing packages that include only Info manuals, which
> document stuff that is not specific to Emacs? Because I don't see how
> it would be a good idea to have this as an ELPA package.
It might be a dedicated ELPA instance if somebody is ready to maintain one.
> . Git manual in Info format
> . Python 3 manual in Info format
Debian offers /usr/share/info/python3.11.info.gz, but not git manual as
info files.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Proposal: Include C Manual from RMS in Emacs git, and/or release
2024-12-02 12:57 ` Eli Zaretskii
2024-12-03 23:03 ` [ELPA] New package c-intro-and-ref -- was " Jeremy Bryant
@ 2024-12-05 5:05 ` Richard Stallman
2024-12-05 6:27 ` Eli Zaretskii
1 sibling, 1 reply; 56+ messages in thread
From: Richard Stallman @ 2024-12-05 5:05 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: jb, emacs-devel
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> > As a general design principle, it doesn't seem to make sense to
> > include all GNU manuals in the Emacs distribution merely because they
> > are useful manuals. The idea was to relese them separately and have
> > them installed separately into a combined info tree.
> >
> > Why is that not working? What needs to be changed in some GNU/Linux
> > distros?
> It does work in general. However, some manuals, which don't belong to
> any project in particular, are largely unknown to exist.
Have you got any ideas for the good ways to inform the community about them?
The two
> prominent examples I have are for some reason both related to the C
> language: gnu-c-manual.info and c.info. The latter is not even
> mentioned in dir-example file that the Texinfo project distributes.
What is c.info? I don't recall hearing about it.
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
^ permalink raw reply [flat|nested] 56+ messages in thread
* Making the GNU C Manual easier to find in Info
2024-12-01 7:45 ` Eli Zaretskii
2024-12-01 8:36 ` Sean Whitton
@ 2024-12-05 5:05 ` Richard Stallman
2024-12-05 6:30 ` Eli Zaretskii
2024-12-05 7:25 ` Integration of Info manuals in programming modes; was: " Dr. Arne Babenhauserheide
1 sibling, 2 replies; 56+ messages in thread
From: Richard Stallman @ 2024-12-05 5:05 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: spwhitton, jb, emacs-devel
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> Isn't the fact that it was mentioned here enough to have it found by a
> browser search?
That is a very low standard of helpfulness. We should aim to be more
helpful than that, with our Info manuals.
> There are a lot of useful manuals that people might not hear about,
> but it doesn't mean it's Emacs's job to solve those problems.
That is true -- helping to make users aware of the GNU C Manual is not
particularly the mission of GNU Emacs. But it is the mission of the
GNU system. We -- the GNU Project -- ought to do a better job of this.
Unfortunately, the GNU Project has no Info Tsar whose job is to plan
changes in various GNU packages to bring the Info system to full
fruition. Can some of us join a discussion about this, perhaos with
some Texinfo developers and others who might be helpful?
How about if those who are interested reply to me. We can have the
discussion somewhere else.
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [ELPA] New package c-intro-and-ref -- was Re: Proposal: Include C Manual from RMS in Emacs git, and/or release
2024-12-04 22:58 ` Jeremy Bryant
@ 2024-12-05 5:45 ` Eli Zaretskii
0 siblings, 0 replies; 56+ messages in thread
From: Eli Zaretskii @ 2024-12-05 5:45 UTC (permalink / raw)
To: Jeremy Bryant; +Cc: rms, emacs-devel, philipk, monnier
> From: Jeremy Bryant <jb@jeremybryant.net>
> Cc: rms@gnu.org, emacs-devel@gnu.org, philipk@posteo.net, Stefan Monnier
> <monnier@iro.umontreal.ca>
> Date: Wed, 04 Dec 2024 22:58:44 +0000
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > Are we providing packages that include only Info manuals, which
> > document stuff that is not specific to Emacs? Because I don't see how
> > it would be a good idea to have this as an ELPA package.
>
> I hear that maybe it's not a good idea, as this is not Emacs specific.
>
> >From a complementary point of view, reading this list it appears that
> there is a smaller number of C contributors to Emacs, compared to Lisp,
> and more C contributors are needed to work on Emacs.
>
> Can we facilitate C documentation?
> For example. The info-look.el subsystem already adds lookup facility for manuals such
> as (libc). Wouldn't it be useful to also have c.info similarly
> available and to aid in Emacs C development? That is
> part of the motivation.
It's okay to extend info-look.el to use this manual (and perhaps also
the sibling GNU C manual?), but please note that we do NOT provide the
glibc Info manual on ELPA, although it is referenced by info-look.el
(and I personally have that manual installed on my system, even though
my main development machine doesn't use glibc).
> The c.texi file starts with a mention of GNU C
>
> @direntry
> * C: (c). GNU C Language Intro and Reference Manual
> @end direntry
Yes.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Proposal: Include C Manual from RMS in Emacs git, and/or release
2024-12-05 5:05 ` Richard Stallman
@ 2024-12-05 6:27 ` Eli Zaretskii
0 siblings, 0 replies; 56+ messages in thread
From: Eli Zaretskii @ 2024-12-05 6:27 UTC (permalink / raw)
To: rms; +Cc: jb, emacs-devel
> From: Richard Stallman <rms@gnu.org>
> Cc: jb@jeremybryant.net, emacs-devel@gnu.org
> Date: Thu, 05 Dec 2024 00:05:13 -0500
>
> > > As a general design principle, it doesn't seem to make sense to
> > > include all GNU manuals in the Emacs distribution merely because they
> > > are useful manuals. The idea was to relese them separately and have
> > > them installed separately into a combined info tree.
> > >
> > > Why is that not working? What needs to be changed in some GNU/Linux
> > > distros?
>
> > It does work in general. However, some manuals, which don't belong to
> > any project in particular, are largely unknown to exist.
>
> Have you got any ideas for the good ways to inform the community about them?
Not immediately, no. I suggest to discuss that with the Texinfo
developers, since they distribute some files that are supposed to
reference all the GNU manuals in existence.
> The two
> > prominent examples I have are for some reason both related to the C
> > language: gnu-c-manual.info and c.info. The latter is not even
> > mentioned in dir-example file that the Texinfo project distributes.
>
> What is c.info? I don't recall hearing about it.
It's your "Introduction to the C language" manual.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Making the GNU C Manual easier to find in Info
2024-12-05 5:05 ` Making the GNU C Manual easier to find in Info Richard Stallman
@ 2024-12-05 6:30 ` Eli Zaretskii
2024-12-05 7:25 ` Integration of Info manuals in programming modes; was: " Dr. Arne Babenhauserheide
1 sibling, 0 replies; 56+ messages in thread
From: Eli Zaretskii @ 2024-12-05 6:30 UTC (permalink / raw)
To: rms; +Cc: spwhitton, jb, emacs-devel
> From: Richard Stallman <rms@gnu.org>
> Cc: spwhitton@spwhitton.name, jb@jeremybryant.net, emacs-devel@gnu.org
> Date: Thu, 05 Dec 2024 00:05:14 -0500
>
> > Isn't the fact that it was mentioned here enough to have it found by a
> > browser search?
>
> That is a very low standard of helpfulness. We should aim to be more
> helpful than that, with our Info manuals.
Agreed. But the place to seek such help is not necessarily here.
> > There are a lot of useful manuals that people might not hear about,
> > but it doesn't mean it's Emacs's job to solve those problems.
>
> That is true -- helping to make users aware of the GNU C Manual is not
> particularly the mission of GNU Emacs. But it is the mission of the
> GNU system. We -- the GNU Project -- ought to do a better job of this.
>
> Unfortunately, the GNU Project has no Info Tsar whose job is to plan
> changes in various GNU packages to bring the Info system to full
> fruition. Can some of us join a discussion about this, perhaos with
> some Texinfo developers and others who might be helpful?
I think the Texinfo developers are the de-fact "czars" of the GNU Info
documentation. So the discussions about this are best held on Texinfo
mailing lists, IMO.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Integration of Info manuals in programming modes; was: Making the GNU C Manual easier to find in Info
2024-12-05 5:05 ` Making the GNU C Manual easier to find in Info Richard Stallman
2024-12-05 6:30 ` Eli Zaretskii
@ 2024-12-05 7:25 ` Dr. Arne Babenhauserheide
2024-12-05 7:46 ` Integration of Info manuals in programming modes Eli Zaretskii
1 sibling, 1 reply; 56+ messages in thread
From: Dr. Arne Babenhauserheide @ 2024-12-05 7:25 UTC (permalink / raw)
To: Richard Stallman; +Cc: Eli Zaretskii, spwhitton, jb, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 935 bytes --]
Richard Stallman <rms@gnu.org> writes:
> > There are a lot of useful manuals that people might not hear about,
> > but it doesn't mean it's Emacs's job to solve those problems.
>
> That is true -- helping to make users aware of the GNU C Manual is not
> particularly the mission of GNU Emacs. But it is the mission of the
> GNU system. We -- the GNU Project -- ought to do a better job of this.
One thing where Info is on-topic here are Emacs integrations.
I remember how useful it was when I had texinfo links directly
available in Emacs:
https://www.draketo.de/light/english/free-software/read-your-python-module-documentation-emacs
This is something that would be really nice to have as default for most
GNU packages in most programming modes.
Do you know other info-to-programming-mode integrations?
Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Texinfo reputation
2024-12-05 4:56 ` Max Nikulin
@ 2024-12-05 7:45 ` Dr. Arne Babenhauserheide
0 siblings, 0 replies; 56+ messages in thread
From: Dr. Arne Babenhauserheide @ 2024-12-05 7:45 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 2520 bytes --]
Max Nikulin <manikulin@gmail.com> writes:
> On 04/12/2024 01:51, Dr. Arne Babenhauserheide wrote:
>> info --usage <package>
>
> Certainly it is more convenient, but a more universal link is still
>
> or available locally via: info '(coreutils) ls invocation'
That is pretty hard to memorize, so while it’s universal, it is
inconvenient (so many people won’t know it when they need it).
>> It nowadays also gives a useful answer when
>> looking for a non-existing manual:
>> info NOTEXISTING
>> info: No menu item 'NOTEXISTING' in node '(dir)Top'
>
> I prefer this behavior as well. It reminds me another recent thread
> however. "info git" renders the man page in my case.
That’s strange: it renders the Git User Manual for me (an infopage).
> Citations in the following
> message gives a fair summary of that discussion
> <https://lists.debian.org/msgid-search/Z0dZjysfE3HE2nJZ@tuxteam.de>
That boils down to "it’s nice but doesn’t always work". Which is a fair
criticism and something that would be great to address technically
(because it can be addressed that way).
>> You even get very fast full-text search through the manuals.
>
> I do not mind, but the real annoyance for new users is that key
> bindings do not match e.g. "less" ones for next match. Mouse support
> in tkinfo makes its usage significantly more intuitive.
Maybe it would be useful to borrow an idea from nano and show the most
important keybindings in the modeline — or initially in the echo area?
What comes to mind:
CTRL-s (search/next result)
N (next)
L (back)
U (up)
SPACE (scroll down)
< (start of manual)
D (directory of all manuals)
I think those are all I use.
(do you know more?)
Maybe alternatively a short list of common keybindings in the info help
manual (that’s pretty long right now, and it contains "please don’t
start skimming" on the third page).
>> And: info --usage git does not give the invocation page — because that
>> node is missing in the manual. That’s not a problem of texinfo, but an
>> indication that something may be missing:
>> Is there a linter for texinfo that remarks such problems?
>
> Perhaps it is possible to write TeX code that spits a warning/error at
> the end of the document when the "invocation" node is missed.
That would be such a linter, yes. And I think it would be pretty useful.
Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Integration of Info manuals in programming modes
2024-12-05 7:25 ` Integration of Info manuals in programming modes; was: " Dr. Arne Babenhauserheide
@ 2024-12-05 7:46 ` Eli Zaretskii
2024-12-05 8:52 ` Visuwesh
` (2 more replies)
0 siblings, 3 replies; 56+ messages in thread
From: Eli Zaretskii @ 2024-12-05 7:46 UTC (permalink / raw)
To: Dr. Arne Babenhauserheide; +Cc: rms, spwhitton, jb, emacs-devel
> From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
> Cc: Eli Zaretskii <eliz@gnu.org>, spwhitton@spwhitton.name,
> jb@jeremybryant.net, emacs-devel@gnu.org
> Date: Thu, 05 Dec 2024 08:25:35 +0100
>
> One thing where Info is on-topic here are Emacs integrations.
>
> I remember how useful it was when I had texinfo links directly
> available in Emacs:
> https://www.draketo.de/light/english/free-software/read-your-python-module-documentation-emacs
Sorry, I don't understand: info-look.el already supports "C-h S" for
Python code, assuming you have a Python manual in Info format
installed. So why would a separate add-on package such as pydoc-info
be needed nowadays? Perhaps it was needed many years ago, when
info-look.el didn't have the Python part? Or what am I missing?
> This is something that would be really nice to have as default for most
> GNU packages in most programming modes.
What other GNU programming packages which have Info manuals and
suitable Emacs major modes are not supported by info-look.el?
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Integration of Info manuals in programming modes
2024-12-05 7:46 ` Integration of Info manuals in programming modes Eli Zaretskii
@ 2024-12-05 8:52 ` Visuwesh
2024-12-05 9:14 ` Eli Zaretskii
2024-12-05 10:06 ` Stephen Berman
2024-12-05 15:07 ` Dr. Arne Babenhauserheide
2 siblings, 1 reply; 56+ messages in thread
From: Visuwesh @ 2024-12-05 8:52 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Dr. Arne Babenhauserheide, rms, spwhitton, jb, emacs-devel
[வியாழன் டிசம்பர் 05, 2024] Eli Zaretskii wrote:
>> This is something that would be really nice to have as default for most
>> GNU packages in most programming modes.
>
> What other GNU programming packages which have Info manuals and
> suitable Emacs major modes are not supported by info-look.el?
f90-mode could look up intrinsic procedures in the gfortran Info manual.
Maybe there is a better for Fortran that I am unaware of. A start would
be
(info-lookup-maybe-add-help
:mode 'f90-mode
:ignore-case t
:regexp "[A-Za-z0-9_]+"
:doc-spec '(("(gfortran)Keyword Index")))
but I do not understand how info-lookup works really. C-h S RET on
'read' jumps to the FGET page which is not we want.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Integration of Info manuals in programming modes
2024-12-05 8:52 ` Visuwesh
@ 2024-12-05 9:14 ` Eli Zaretskii
2024-12-05 9:49 ` Visuwesh
0 siblings, 1 reply; 56+ messages in thread
From: Eli Zaretskii @ 2024-12-05 9:14 UTC (permalink / raw)
To: Visuwesh; +Cc: arne_bab, rms, spwhitton, jb, emacs-devel
> From: Visuwesh <visuweshm@gmail.com>
> Cc: "Dr. Arne Babenhauserheide" <arne_bab@web.de>, rms@gnu.org,
> spwhitton@spwhitton.name, jb@jeremybryant.net, emacs-devel@gnu.org
> Date: Thu, 05 Dec 2024 14:22:41 +0530
>
> [வியாழன் டிசம்பர் 05, 2024] Eli Zaretskii wrote:
>
> > What other GNU programming packages which have Info manuals and
> > suitable Emacs major modes are not supported by info-look.el?
>
> f90-mode could look up intrinsic procedures in the gfortran Info manual.
> Maybe there is a better for Fortran that I am unaware of. A start would
> be
>
> (info-lookup-maybe-add-help
> :mode 'f90-mode
> :ignore-case t
> :regexp "[A-Za-z0-9_]+"
> :doc-spec '(("(gfortran)Keyword Index")))
We could definitely add something like that, but is it specific to
f90-mode? What about other Fortran modes?
> but I do not understand how info-lookup works really. C-h S RET on
> 'read' jumps to the FGET page which is not we want.
Look at the index node you mentioned: what other menu item that
matches "read" there is more appropriate? And what did you expect to
see instead?
The gfortran manual doesn't seem to describe the Fortran language,
only the GNU-specific extensions or something. It lacks basic Fortran
keywords. Perhaps that is the source of your confusion?
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Integration of Info manuals in programming modes
2024-12-05 9:14 ` Eli Zaretskii
@ 2024-12-05 9:49 ` Visuwesh
2024-12-05 11:17 ` Eli Zaretskii
0 siblings, 1 reply; 56+ messages in thread
From: Visuwesh @ 2024-12-05 9:49 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: arne_bab, rms, spwhitton, jb, emacs-devel
[வியாழன் டிசம்பர் 05, 2024] Eli Zaretskii wrote:
>> From: Visuwesh <visuweshm@gmail.com>
>> Cc: "Dr. Arne Babenhauserheide" <arne_bab@web.de>, rms@gnu.org,
>> spwhitton@spwhitton.name, jb@jeremybryant.net, emacs-devel@gnu.org
>> Date: Thu, 05 Dec 2024 14:22:41 +0530
>>
>> [வியாழன் டிசம்பர் 05, 2024] Eli Zaretskii wrote:
>>
>> > What other GNU programming packages which have Info manuals and
>> > suitable Emacs major modes are not supported by info-look.el?
>>
>> f90-mode could look up intrinsic procedures in the gfortran Info manual.
>> Maybe there is a better for Fortran that I am unaware of. A start would
>> be
>>
>> (info-lookup-maybe-add-help
>> :mode 'f90-mode
>> :ignore-case t
>> :regexp "[A-Za-z0-9_]+"
>> :doc-spec '(("(gfortran)Keyword Index")))
>
> We could definitely add something like that, but is it specific to
> f90-mode? What about other Fortran modes?
I am ignorant in that regard. I only ever look at Fortran 90 code, I
rarely, if ever, need to look at Fortran 77 code (so I'm saved in that
regard).
>> but I do not understand how info-lookup works really. C-h S RET on
>> 'read' jumps to the FGET page which is not we want.
>
> Look at the index node you mentioned: what other menu item that
> matches "read" there is more appropriate? And what did you expect to
> see instead?
I would rather see a complain about no matches. If someone could figure
out how to reject non-exact matches, that would be do the job.
> The gfortran manual doesn't seem to describe the Fortran language,
> only the GNU-specific extensions or something. It lacks basic Fortran
> keywords. Perhaps that is the source of your confusion?
It documents intrinsic functions and subroutines. It is by no means a
complete manual for the Fortran language though. It is no small wonder
that keywords are not documented. I have been looking for such a manual
to no avail.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Integration of Info manuals in programming modes
2024-12-05 7:46 ` Integration of Info manuals in programming modes Eli Zaretskii
2024-12-05 8:52 ` Visuwesh
@ 2024-12-05 10:06 ` Stephen Berman
2024-12-05 15:07 ` Dr. Arne Babenhauserheide
2 siblings, 0 replies; 56+ messages in thread
From: Stephen Berman @ 2024-12-05 10:06 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Dr. Arne Babenhauserheide, rms, spwhitton, jb, emacs-devel
On Thu, 05 Dec 2024 09:46:05 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
> What other GNU programming packages which have Info manuals and
> suitable Emacs major modes are not supported by info-look.el?
R (cf. https://www.r-project.org/about.html: "R is a language and
environment for statistical computing and graphics. It is a GNU
project..."). An R installation comes with several Info manuals.
However, I guess many or perhaps most Emacs users who use R use it with
ESS (available from GNU ELPA), which implements comprehensive help
itegration for R, so for such users info-look integration may be
superfluous. But it would be helpful for those R+Emacs users who don't
use ESS. (I could try to make a patch to add support for R to
info-look, but I'm not familiar with info-look, so it could take me some
time.)
Steve Berman
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Integration of Info manuals in programming modes
2024-12-05 9:49 ` Visuwesh
@ 2024-12-05 11:17 ` Eli Zaretskii
2024-12-05 11:28 ` Visuwesh
0 siblings, 1 reply; 56+ messages in thread
From: Eli Zaretskii @ 2024-12-05 11:17 UTC (permalink / raw)
To: Visuwesh; +Cc: arne_bab, rms, spwhitton, jb, emacs-devel
> From: Visuwesh <visuweshm@gmail.com>
> Cc: arne_bab@web.de, rms@gnu.org, spwhitton@spwhitton.name,
> jb@jeremybryant.net, emacs-devel@gnu.org
> Date: Thu, 05 Dec 2024 15:19:13 +0530
>
> [வியாழன் டிசம்பர் 05, 2024] Eli Zaretskii wrote:
>
> >> but I do not understand how info-lookup works really. C-h S RET on
> >> 'read' jumps to the FGET page which is not we want.
> >
> > Look at the index node you mentioned: what other menu item that
> > matches "read" there is more appropriate? And what did you expect to
> > see instead?
>
> I would rather see a complain about no matches. If someone could figure
> out how to reject non-exact matches, that would be do the job.
That's a double-edge sword: rejecting non-exact matches could miss
valid hits.
However, maybe the regexp should only match keywords in upper-case,
and ignore-case should not be used?
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Integration of Info manuals in programming modes
2024-12-05 11:17 ` Eli Zaretskii
@ 2024-12-05 11:28 ` Visuwesh
2024-12-05 12:01 ` Eli Zaretskii
0 siblings, 1 reply; 56+ messages in thread
From: Visuwesh @ 2024-12-05 11:28 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: arne_bab, rms, spwhitton, jb, emacs-devel
[வியாழன் டிசம்பர் 05, 2024] Eli Zaretskii wrote:
>> From: Visuwesh <visuweshm@gmail.com>
>> Cc: arne_bab@web.de, rms@gnu.org, spwhitton@spwhitton.name,
>> jb@jeremybryant.net, emacs-devel@gnu.org
>> Date: Thu, 05 Dec 2024 15:19:13 +0530
>>
>> [வியாழன் டிசம்பர் 05, 2024] Eli Zaretskii wrote:
>>
>> >> but I do not understand how info-lookup works really. C-h S RET on
>> >> 'read' jumps to the FGET page which is not we want.
>> >
>> > Look at the index node you mentioned: what other menu item that
>> > matches "read" there is more appropriate? And what did you expect to
>> > see instead?
>>
>> I would rather see a complain about no matches. If someone could figure
>> out how to reject non-exact matches, that would be do the job.
>
> That's a double-edge sword: rejecting non-exact matches could miss
> valid hits.
I agree, dismissing a invalid match is not too much trouble.
> However, maybe the regexp should only match keywords in upper-case,
> and ignore-case should not be used?
But Fortran is a case-insensitive language and recent style-guides ask
you to use lower case lettering for everything. Other code that I've
seen use upper case lettering for keywords, not for functions and
subroutines so we cannot opt for this route unfortunately.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Integration of Info manuals in programming modes
2024-12-05 11:28 ` Visuwesh
@ 2024-12-05 12:01 ` Eli Zaretskii
2024-12-05 12:39 ` Visuwesh
0 siblings, 1 reply; 56+ messages in thread
From: Eli Zaretskii @ 2024-12-05 12:01 UTC (permalink / raw)
To: Visuwesh; +Cc: arne_bab, rms, spwhitton, jb, emacs-devel
> From: Visuwesh <visuweshm@gmail.com>
> Cc: arne_bab@web.de, rms@gnu.org, spwhitton@spwhitton.name,
> jb@jeremybryant.net, emacs-devel@gnu.org
> Date: Thu, 05 Dec 2024 16:58:22 +0530
>
> [வியாழன் டிசம்பர் 05, 2024] Eli Zaretskii wrote:
>
> >> From: Visuwesh <visuweshm@gmail.com>
> >> Cc: arne_bab@web.de, rms@gnu.org, spwhitton@spwhitton.name,
> >> jb@jeremybryant.net, emacs-devel@gnu.org
> >> Date: Thu, 05 Dec 2024 15:19:13 +0530
> >>
> >> [வியாழன் டிசம்பர் 05, 2024] Eli Zaretskii wrote:
> >>
> >> >> but I do not understand how info-lookup works really. C-h S RET on
> >> >> 'read' jumps to the FGET page which is not we want.
> >> >
> >> > Look at the index node you mentioned: what other menu item that
> >> > matches "read" there is more appropriate? And what did you expect to
> >> > see instead?
> >>
> >> I would rather see a complain about no matches. If someone could figure
> >> out how to reject non-exact matches, that would be do the job.
> >
> > That's a double-edge sword: rejecting non-exact matches could miss
> > valid hits.
>
> I agree, dismissing a invalid match is not too much trouble.
>
> > However, maybe the regexp should only match keywords in upper-case,
> > and ignore-case should not be used?
>
> But Fortran is a case-insensitive language and recent style-guides ask
> you to use lower case lettering for everything. Other code that I've
> seen use upper case lettering for keywords, not for functions and
> subroutines so we cannot opt for this route unfortunately.
What is important in this context is not whether Fortran is
case-insensitive, but how the index of the manual spells the keywords.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Integration of Info manuals in programming modes
2024-12-05 12:01 ` Eli Zaretskii
@ 2024-12-05 12:39 ` Visuwesh
2024-12-05 14:26 ` Eli Zaretskii
0 siblings, 1 reply; 56+ messages in thread
From: Visuwesh @ 2024-12-05 12:39 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: arne_bab, rms, spwhitton, jb, emacs-devel
[வியாழன் டிசம்பர் 05, 2024] Eli Zaretskii wrote:
>> > However, maybe the regexp should only match keywords in upper-case,
>> > and ignore-case should not be used?
>>
>> But Fortran is a case-insensitive language and recent style-guides ask
>> you to use lower case lettering for everything. Other code that I've
>> seen use upper case lettering for keywords, not for functions and
>> subroutines so we cannot opt for this route unfortunately.
>
> What is important in this context is not whether Fortran is
> case-insensitive, but how the index of the manual spells the keywords.
I do not really understand how info-lookup does its job but 'read' still
matches if I use
(info-lookup-maybe-add-help
:mode 'f90-mode
:parse-rule "[A-Za-z0-9_]+"
:regexp "[A-Z0-9_]+"
:doc-spec '(("(gfortran)Keyword Index")))
instead. Perhaps I do not understand what you have in mind.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Integration of Info manuals in programming modes
2024-12-05 12:39 ` Visuwesh
@ 2024-12-05 14:26 ` Eli Zaretskii
0 siblings, 0 replies; 56+ messages in thread
From: Eli Zaretskii @ 2024-12-05 14:26 UTC (permalink / raw)
To: Visuwesh; +Cc: arne_bab, rms, spwhitton, jb, emacs-devel
> From: Visuwesh <visuweshm@gmail.com>
> Cc: arne_bab@web.de, rms@gnu.org, spwhitton@spwhitton.name,
> jb@jeremybryant.net, emacs-devel@gnu.org
> Date: Thu, 05 Dec 2024 18:09:39 +0530
>
> [வியாழன் டிசம்பர் 05, 2024] Eli Zaretskii wrote:
>
> >> > However, maybe the regexp should only match keywords in upper-case,
> >> > and ignore-case should not be used?
> >>
> >> But Fortran is a case-insensitive language and recent style-guides ask
> >> you to use lower case lettering for everything. Other code that I've
> >> seen use upper case lettering for keywords, not for functions and
> >> subroutines so we cannot opt for this route unfortunately.
> >
> > What is important in this context is not whether Fortran is
> > case-insensitive, but how the index of the manual spells the keywords.
>
> I do not really understand how info-lookup does its job but 'read' still
> matches if I use
>
> (info-lookup-maybe-add-help
> :mode 'f90-mode
> :parse-rule "[A-Za-z0-9_]+"
> :regexp "[A-Z0-9_]+"
> :doc-spec '(("(gfortran)Keyword Index")))
>
> instead. Perhaps I do not understand what you have in mind.
Maybe it's deeper in the bowels of the code, maybe even in info.el.
E.g., info.el could bind case-fold-search non-nil when looking up
index items.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Integration of Info manuals in programming modes
2024-12-05 7:46 ` Integration of Info manuals in programming modes Eli Zaretskii
2024-12-05 8:52 ` Visuwesh
2024-12-05 10:06 ` Stephen Berman
@ 2024-12-05 15:07 ` Dr. Arne Babenhauserheide
2024-12-05 16:04 ` Eli Zaretskii
2 siblings, 1 reply; 56+ messages in thread
From: Dr. Arne Babenhauserheide @ 2024-12-05 15:07 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: rms, spwhitton, jb, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1750 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
>> From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
>> Cc: Eli Zaretskii <eliz@gnu.org>, spwhitton@spwhitton.name,
>> jb@jeremybryant.net, emacs-devel@gnu.org
>> Date: Thu, 05 Dec 2024 08:25:35 +0100
>>
>> One thing where Info is on-topic here are Emacs integrations.
>>
>> I remember how useful it was when I had texinfo links directly
>> available in Emacs:
>> https://www.draketo.de/light/english/free-software/read-your-python-module-documentation-emacs
>
> Sorry, I don't understand: info-look.el already supports "C-h S" for
…
> installed. So why would a separate add-on package such as pydoc-info
> be needed nowadays? Perhaps it was needed many years ago, when
> info-look.el didn't have the Python part? Or what am I missing?
I’d rather think that *I* was missing info-look.el
>> This is something that would be really nice to have as default for most
>> GNU packages in most programming modes.
>
> What other GNU programming packages which have Info manuals and
Many Python packages *could have* info manuals when their documentation
can be parsed to info (as for example by Sphinx — that’s the essential
part of the article).
So that’s something we could encourage packagers to do.
Can I get info completion from LaTeX? I’d think that pandoc can
transpile most of the extensive LaTeX package documentation to
texinfo/info.
⇒ besides some (now) smaller tooling issues, I see the biggest drawback
in not having all available that could be in info with not too much
effort.
Do other distros have more info manuals than Guix?
Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Integration of Info manuals in programming modes
2024-12-05 15:07 ` Dr. Arne Babenhauserheide
@ 2024-12-05 16:04 ` Eli Zaretskii
0 siblings, 0 replies; 56+ messages in thread
From: Eli Zaretskii @ 2024-12-05 16:04 UTC (permalink / raw)
To: Dr. Arne Babenhauserheide; +Cc: rms, spwhitton, jb, emacs-devel
> From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
> Cc: rms@gnu.org, spwhitton@spwhitton.name, jb@jeremybryant.net,
> emacs-devel@gnu.org
> Date: Thu, 05 Dec 2024 16:07:35 +0100
>
> Can I get info completion from LaTeX?
Yes, if you have the manual.
> Do other distros have more info manuals than Guix?
I don't know.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [ELPA] New package c-intro-and-ref -- was Re: Proposal: Include C Manual from RMS in Emacs git, and/or release
2024-12-04 12:33 ` Eli Zaretskii
2024-12-04 22:58 ` Jeremy Bryant
2024-12-05 5:03 ` Max Nikulin
@ 2024-12-05 18:47 ` Philip Kaludercic
2024-12-05 19:04 ` Eli Zaretskii
2024-12-05 19:17 ` Stefan Monnier
2 siblings, 2 replies; 56+ messages in thread
From: Philip Kaludercic @ 2024-12-05 18:47 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Jeremy Bryant, rms, emacs-devel, Stefan Monnier
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Jeremy Bryant <jb@jeremybryant.net>
>> Cc: rms@gnu.org, emacs-devel@gnu.org, Philip Kaludercic <philipk@posteo.net>
>> Date: Tue, 03 Dec 2024 23:03:42 +0000
>>
>> I have created a prototype ELPA package, comments welcome?
>
> Are we providing packages that include only Info manuals, which
> document stuff that is not specific to Emacs? Because I don't see how
> it would be a good idea to have this as an ELPA package.
>
> But if we do accept such packages on ELPA, then I have 2 additional
> similar suggestions:
>
> . Git manual in Info format
> . Python 3 manual in Info format
It would also make sense to make the Emacs manuals available for easy
download, as distributions like Debian do not include these by default.
Whether we distribute these by piggy-backing on package.el or have a
separate installer that could be distributed on ELPA is a different
matter, but it would be useful to have an index of already existing
manuals that would be interesting regardless of their relation to Emacs.
>> Current Package name, proposed for ELPA: c-intro-and-ref
>> This matches the existing manual distribution.
>> Perhaps a name such as: gnu-c-manual
>
> That'd be wrong, since this manual doesn't describe GNU C, it
> describes the C language in general. (There's a separate GNU C
> manual, btw.)
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [ELPA] New package c-intro-and-ref -- was Re: Proposal: Include C Manual from RMS in Emacs git, and/or release
2024-12-05 18:47 ` Philip Kaludercic
@ 2024-12-05 19:04 ` Eli Zaretskii
2024-12-05 19:17 ` Stefan Monnier
1 sibling, 0 replies; 56+ messages in thread
From: Eli Zaretskii @ 2024-12-05 19:04 UTC (permalink / raw)
To: Philip Kaludercic; +Cc: jb, rms, emacs-devel, monnier
> From: Philip Kaludercic <philipk@posteo.net>
> Cc: Jeremy Bryant <jb@jeremybryant.net>, rms@gnu.org, emacs-devel@gnu.org,
> Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 05 Dec 2024 18:47:31 +0000
>
> It would also make sense to make the Emacs manuals available for easy
> download
The Emacs manuals are part of the release tarballs, so they are
already easily donwloadable: just download the release tarball, unpack
it, and take all the files from the info/ subdirectory.
^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: [ELPA] New package c-intro-and-ref -- was Re: Proposal: Include C Manual from RMS in Emacs git, and/or release
2024-12-05 18:47 ` Philip Kaludercic
2024-12-05 19:04 ` Eli Zaretskii
@ 2024-12-05 19:17 ` Stefan Monnier
1 sibling, 0 replies; 56+ messages in thread
From: Stefan Monnier @ 2024-12-05 19:17 UTC (permalink / raw)
To: Philip Kaludercic; +Cc: Eli Zaretskii, Jeremy Bryant, rms, emacs-devel
>> Are we providing packages that include only Info manuals, which
>> document stuff that is not specific to Emacs? Because I don't see how
>> it would be a good idea to have this as an ELPA package.
There is a precedent in the form of the [Ada reference
manual](http://elpa.gnu.org/packages/ada-ref-man.html).
FWIW, I'm not completely comfortable with this precedent.
Sadly Info is rarely used outside of Emacs FAICT, so there is a clear
tendency to consider Info manual as "manuals for use within Emacs".
> It would also make sense to make the Emacs manuals available for easy
> download, as distributions like Debian do not include these by default.
> Whether we distribute these by piggy-backing on package.el or have a
> separate installer that could be distributed on ELPA is a different
> matter, but it would be useful to have an index of already existing
> manuals that would be interesting regardless of their relation to Emacs.
A dedicated ELisp package that can download manuals and install them in
Info format (which may require converting from another format) would be
nice (or more generally in any format that Emacs can use, which may also
include HTML, nowadays, tho we still need extra work to make HTML
manuals as well integrated as Info manuals).
Stefan
^ permalink raw reply [flat|nested] 56+ messages in thread
end of thread, other threads:[~2024-12-05 19:17 UTC | newest]
Thread overview: 56+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-11-30 12:56 Proposal: Include C Manual from RMS in Emacs git, and/or release Jeremy Bryant
2024-11-30 13:25 ` Philip Kaludercic
2024-11-30 13:38 ` Arsen Arsenović
2024-11-30 14:12 ` Eli Zaretskii
2024-11-30 18:08 ` Arsen Arsenović
2024-11-30 20:05 ` Eli Zaretskii
2024-11-30 21:09 ` [External] : " Drew Adams
2024-12-01 6:15 ` Eli Zaretskii
2024-12-02 3:00 ` Texinfo reputation (was: Re: [External] : Re: Proposal: Include C Manual from RMS in Emacs git, and/or release) Max Nikulin
2024-12-02 12:47 ` Eli Zaretskii
2024-12-03 2:51 ` Texinfo reputation Max Nikulin
2024-12-03 12:38 ` Eli Zaretskii
2024-12-03 18:51 ` Dr. Arne Babenhauserheide
2024-12-05 4:56 ` Max Nikulin
2024-12-05 7:45 ` Dr. Arne Babenhauserheide
2024-12-01 9:53 ` Proposal: Include C Manual from RMS in Emacs git, and/or release Arsen Arsenović
2024-12-01 10:12 ` Eli Zaretskii
2024-12-01 10:54 ` Arsen Arsenović
2024-12-01 13:04 ` Johan Myréen
2024-12-04 6:09 ` Richard Stallman
2024-11-30 13:50 ` Eli Zaretskii
2024-12-01 4:02 ` Sean Whitton
2024-12-01 7:45 ` Eli Zaretskii
2024-12-01 8:36 ` Sean Whitton
2024-12-01 10:01 ` Eli Zaretskii
2024-12-01 11:13 ` Sean Whitton
2024-12-05 5:05 ` Making the GNU C Manual easier to find in Info Richard Stallman
2024-12-05 6:30 ` Eli Zaretskii
2024-12-05 7:25 ` Integration of Info manuals in programming modes; was: " Dr. Arne Babenhauserheide
2024-12-05 7:46 ` Integration of Info manuals in programming modes Eli Zaretskii
2024-12-05 8:52 ` Visuwesh
2024-12-05 9:14 ` Eli Zaretskii
2024-12-05 9:49 ` Visuwesh
2024-12-05 11:17 ` Eli Zaretskii
2024-12-05 11:28 ` Visuwesh
2024-12-05 12:01 ` Eli Zaretskii
2024-12-05 12:39 ` Visuwesh
2024-12-05 14:26 ` Eli Zaretskii
2024-12-05 10:06 ` Stephen Berman
2024-12-05 15:07 ` Dr. Arne Babenhauserheide
2024-12-05 16:04 ` Eli Zaretskii
2024-12-02 4:10 ` Proposal: Include C Manual from RMS in Emacs git, and/or release Richard Stallman
2024-12-02 12:57 ` Eli Zaretskii
2024-12-03 23:03 ` [ELPA] New package c-intro-and-ref -- was " Jeremy Bryant
2024-12-04 12:33 ` Eli Zaretskii
2024-12-04 22:58 ` Jeremy Bryant
2024-12-05 5:45 ` Eli Zaretskii
2024-12-05 5:03 ` Max Nikulin
2024-12-05 18:47 ` Philip Kaludercic
2024-12-05 19:04 ` Eli Zaretskii
2024-12-05 19:17 ` Stefan Monnier
2024-12-04 20:02 ` Suhail Singh
[not found] ` <87wmgf9h70.fsf@jeremybryant.net>
2024-12-04 23:52 ` Suhail Singh
2024-12-05 5:05 ` Richard Stallman
2024-12-05 6:27 ` Eli Zaretskii
2024-12-03 20:07 ` Björn Bidar
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).