Re: Improve access to documentation in Info format

["Björn Bidar" <bjorn.bidar@thaodan.de>]

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. ]]]
>
>   > 1. Providing an "easy" way for users to see available info manuals and
>   >    install them.
>
> I think we should be able to do this.  The way I see is involves two
> steps:
>
> a, Set up some sort of download repo with all the Info manuals.
>
> b. Write software to find the desired manual, fetch it, and install it
> on your computer.

That's the users package manager in almost all the cases. If not the
solutions mentioned by Suhail Singh are an option.

Writing a new software for this isn't a good idea IMHO.

Writing build scrits/descriptions for all the possible package managers
we could face should be much easier.

I wouldn't do this for ALL info manuals but only for those where are
no packages for. For those where a conversion to Texinfo is done
e.g. Sphinx like for example when packaging CMake it easier to add the
info manual packaging to existing packaging.

Add that is a very minor change and could be done by users interested
into having these info manuals with little amount of time.
Guix is a good place for examples of these efforts.

> Would people like tp vplunteer to work on this?
>
>   > 2. Make it easier to generate and perhaps also provide, via 1, Info
>   >    manuals for packages that use other documentation generation systems.
>   >    A popular candidate to target in this regard is Sphinx.  Sphinx has
>   >    some existing support, IIUC, to generate Texinfo output.
>
> In principle I think this is a good idea, but there is a technical
> difficulty: it is impossible to produce a fully correct Info manual
> from those other formats. because those other formats do not make
> the necessary distincions.

Info being the minority in this instance would be in the position
to improve the output of these engines.

It would be best to approach this diplomatic.

> It would not be terribly hard to write software which would do this
> job _as well as could be done given the current formats_, but the
> results will be visibly wrong.
>
> What would be terribly hard is to do a better job than that.