Re: SCWM's embedded docs/text proc benchmarks/perl's 10x faster than guile.

[Telford Tendys <telford@triangle.triode.net.au>]

> > not as long as the FSF sticks behind it.
> 
> Hopefully, we can come up with something better, and the FSF will switch,
> once the tools are there, and there is a transition strategy.

Just a reminder that it is all we can do to keep guile upright,
leaning on the FSF to take a step to the left isn't something that I
personally feel responsible for.

> >    Per> features (that people these days *expect*) that info does not
> >    Per> handle.  There is nothing in info that cannot be expressed
> >
> > please elaborate.
> 
> Graphics, math, colors, fonts.  I agree fonts are a frill for
> most documentation, but they make the docuemntation look both
> nicer and more readable,

Fonts are supported in texinfo but only where it suits the markup
(e.g. for headings, function names, etc). The ability to put arbitrary
fonts wherever you like seems pointless in this application.
Fonts in info are not supported because info runs on character terminals,
most of which don't support fonts. If you want something fancy that
you can read online then by all means make postscript output and view
it with ghostscript. Why does no one do it this way? Because it is painfully
slow. About as slow as running a GUI web browser with fancy fonts and
colours. My main concerns regarding online documentation are:

	* Completeness
	* Good index (and search facilities)
	* Fast access

Graphics would be nice but aren't essential. Math is also nice but
you have to convert the equations to ASCII sometime in order to program
them. Full fledged derivations and proofs don't belong in the online
documentation, they belong in journal articles or at least something that
is going to be printed and studied.

> and why should online documentation look
> crappier than printed documentation in this day and age?

In my book there is nothing crappy about plain text.
You are going to want fonts and colours in your source code next.
Give me speed and simplicity over frills any day.

> No, my attitude is that *today* *standard* html supports all the
> ease of browsing that the info format has.  The problem is not html;
> it is that most *browsers* do not not support hierarchical browsing
> as well as the info *program*.  That is a relatively easy matter
> of changing some key-bindings.

It is all work that needs doing. Worse still, guile users will have to
download a modified browser to be able to read the docs. When the HTML
standard has settled enough that browser writers actually catch up to
what the standard supports then it will be more usable in this application.

> Because it is a dead-end, non-extensible, lacks critical features,
> does not have visual appeal (important for marketing of GNU, if
> nothing else), has very little use outside GNU, and because all its
> features can be subsumed by something better *and* more popular.

Nothing is dead-end when you have the source, there is nothing stopping
people adding stuff to the info standard but most people don't want to.
The features it lacks are not critical _for_program_documentation_,
no one is suggesting the use of info as a marketing tool to generate
billboards. The fact that it can't be used for this purpose makes me
trust it so much the more.

> Info was great;  it is time to move forwards.  We are no longer limited
> to character-based user-interfaces, and people expect more.

If you are going to make fonts and colours into critical features then
I probably won't be able to use lynx to browse the help pages either.
In that case I'm forced away from my character based interface and I can't
help feeling that gives me LESS than before (walking backwards).

Unix was made on the principle of `do one thing and do it well'.
The purpose of guile is to make a good scripting language, not to push
the envelope of documentation formatting. The whole idea of the doc
extractor is to result in less work to do when generating documentation.

	- Tel

PS: I do see SGML as the future standard, possibly replacing even LaTeX
(eventually) but I don't want to have to drag it there by myself.