Re: doc value of regtests: none

[Trevor Bača]

On 8/31/07, Graham Percival <address@hidden> wrote:
> Valentin Villenave wrote:
> > 2007/8/31, Graham Percival <address@hidden <mailto:address@hidden>>:
> >
> > > The *only* reason that the regtests are still on the main doc page is
> > > that it gives us a nice set of 3 4x4 blocks of items.  If I wasn't so
> > > fussy (obsessive? :) about presentation, I'd remove it from that page in
> > > an instant.
> >
> > ahahaha :)
> > I wondered why the link was still here...
> > For what it's worth, I often say to myself that the Bibligraphy link
> > is not mandatory.
> > Besides, it would be nice if the Program usage was aligned with the
> > User manual.
> > What about the following presentation?
> It's certainly tempting.  We'd need to move the current "Bibliography"
> info into Appendix A "Literature List"  (I don't know why they're
> separate, anyway).
>
> Anybody else have thoughts about this?

I like it; smaller (on the frontpage) is better. And the bib can
certainly be shoved into an appendix (though it's a very interesting
read every couple of months).

While we're on it, can I ask whether anyone else would like to see the
program reference (NOT the frontpage) flattened out? Ie, instead of
these five categories ...


    * Music definitions: Definition of the input data structures.
    * Translation: From music to layout.
    * Backend: Reference for the layout engine.
    * Scheme functions: Primitive functions exported by LilyPond.
    * Indexes

... could we have this?

    * Music expressions: Objects that represent music.
    * Music classes
    * Music properties: All music properties, including descriptions.

    * Contexts: Complete descriptions of all contexts.
    * Engravers: All separate engravers.
    * Tunable context properties: All tunable context properties.
    * Internal context properties: All internal context properties.

    * All layout objects: Description and defaults for all graphical
objects (grobs).
    * Graphical Object Interfaces: Building blocks of graphical objects.
    * User backend properties: All tunable properties in a big list.
    * Internal backend properties: All internal layout properties in a
big list.

    * Scheme functions: Primitive functions exported by LilyPond.
    * Indexes


The reason I ask is that I've always found the top-level distinction
between "Translation" and "Backend" to be extraordinarily confusing.
This may very well be just me. But easily 90% of my usage of the
program reference is to click on a grob and see what interfaces the
grob supports. To do this I click Program Reference > Translation >
Contexts > [realize I have the wrong list] > Back > Back > Backend >
All layout Objects > [whichever grob]. I may be the only who makes
this mistake but it just seems odd to me that I would keep making the
mistake for going on two years now if we just put a label for "All
layout objects" front an center (like above), thus privileging the
inspect-grob-doc use case.

Anyone else make this mistake? Or do I just need to make better use of
Camino's bookmarks? ;-)


-- 
Trevor Bača
address@hidden