Yes, it has an info manual and, I agree, info is the superior documentation viewer. However, a good browser is no replacement for bad writing.

The Guile manual is not well written. The organization seems almost random. The text emphasizes minutia while glossing over fundamental details. It off-loads much to RnRSs and SFRIs (whatever those are). Basically, it suffers badly from The Curse of Expertise.

The documentation's shortcomings might be okay except that Guile is, or was, the premier extension language for the whole of the GNU project.

I considered trying to improve the manual, but why would I dedicate time and effort to a language that I don't know and whose community can't follow it's own advice?

Consider the following:

"Make sure your manual is clear to a reader who knows nothing about the topic and reads it straight through. This means covering basic topics at the beginning, and advanced topics only later. This also means defining every specialized term when it is first used." https://www.gnu.org/prep/standards/html_node/GNU-Manuals.htm...

Most of these points: https://www.fsf.org/campaigns/gnu-press/GNU-Press-styleguide...

Maybe at FOSDEM this year, people could do a Hackathon and knock out some basics, like defining acronyms or using terms only after they're defined.

PS: every Python tarball for quite a while has instructions for building the documentation, including in info format

Software is art. Maybe someone out there somehow gets 10xd from these traits, but highly unlikely

One funny thing I just noticed: I am not the only one often mistyping "PFDS" as "PDFs" (usually in lowercase though). On IJP's repo for "fectors":

> One such implementation is based on fingertrees and is provided as part of my pdfs package[1]

(I have been enjoying Elixir too, but at the end of the day it doesn’t quite sit right with me — just feels a bit clunky. Gleam seems an attractive alternative though. The BEAM rocks, but it is a heavy dependency that doesn’t fit all distribution needs.)