Proposal: Include C Manual from RMS in Emacs git, and/or release

Proposal: Include C Manual from RMS in Emacs git, and/or release

[Jeremy Bryant]

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?

Re: Proposal: Include C Manual from RMS in Emacs git, and/or release

[Philip Kaludercic]

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).

Re: Proposal: Include C Manual from RMS in Emacs git, and/or release

[Arsen Arsenović]

[-- 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 --]

Re: Proposal: Include C Manual from RMS in Emacs git, and/or release

[Eli Zaretskii]

> 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?

Re: Proposal: Include C Manual from RMS in Emacs git, and/or release

[Arsen Arsenović]

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ć

Re: Proposal: Include C Manual from RMS in Emacs git, and/or release

[Eli Zaretskii]

> 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.

RE: [External] : Re: Proposal: Include C Manual from RMS in Emacs git, and/or release

[Drew Adams]

> 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.

Re: [External] : Re: Proposal: Include C Manual from RMS in Emacs git, and/or release

[Eli Zaretskii]

> 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.

Texinfo reputation (was: Re: [External] : Re: Proposal: Include C Manual from RMS in Emacs git, and/or release)

[Max Nikulin]

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?

Re: Texinfo reputation (was: Re: [External] : Re: Proposal: Include C Manual from RMS in Emacs git, and/or release)

[Eli Zaretskii]

> 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.

Re: Texinfo reputation

[Max Nikulin]

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.

Re: Texinfo reputation

[Eli Zaretskii]

> 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.

Re: Texinfo reputation

[Dr. Arne Babenhauserheide]

[-- 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 --]

Re: Proposal: Include C Manual from RMS in Emacs git, and/or release

[Arsen Arsenović]

[-- 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 --]

Re: Proposal: Include C Manual from RMS in Emacs git, and/or release

[Eli Zaretskii]

> 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?

Re: Proposal: Include C Manual from RMS in Emacs git, and/or release

[Arsen Arsenović]

[-- 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 --]

Re: Proposal: Include C Manual from RMS in Emacs git, and/or release

[Johan Myréen]

[-- 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 --]

Re: Proposal: Include C Manual from RMS in Emacs git, and/or release

[Richard Stallman]

[[[ 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)

Re: Proposal: Include C Manual from RMS in Emacs git, and/or release

[Eli Zaretskii]

> 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.

Re: Proposal: Include C Manual from RMS in Emacs git, and/or release

[Sean Whitton]

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

Re: Proposal: Include C Manual from RMS in Emacs git, and/or release

[Eli Zaretskii]

> 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.

Re: Proposal: Include C Manual from RMS in Emacs git, and/or release

[Sean Whitton]

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

Re: Proposal: Include C Manual from RMS in Emacs git, and/or release

[Eli Zaretskii]

> 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?

Re: Proposal: Include C Manual from RMS in Emacs git, and/or release

[Sean Whitton]

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

Re: Proposal: Include C Manual from RMS in Emacs git, and/or release

[Richard Stallman]

[[[ 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)

Re: Proposal: Include C Manual from RMS in Emacs git, and/or release

[Eli Zaretskii]

> 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.

[ELPA] New package c-intro-and-ref -- was Re: Proposal: Include C Manual from RMS in Emacs git, and/or release

[Jeremy Bryant]

[-- 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 --]

Re: Proposal: Include C Manual from RMS in Emacs git, and/or release

[Björn Bidar]

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.