Re: GDP: rearrange manual

[Eyolf Østrem]

On 09.09.2007 (16:32), Graham Percival wrote:
> Well, don't I feel like a complete newbie.  :/    Does anybody know how to 
> make Thunderbird treat text like pure bloody text, and not change the 
> displayed text when it sends an email out?  thanks in advance.  :(

One of the reasons why I prefer mutt over any other mail handler...
perfect example of the difference between "user-friendliness" and
*user-friendliness*.

Anyway, I second the suggestions that ... 

On 09.09.2007 (18:06), Trevor Bača made:
> 
> Specifically:
> 
> - promote section 8.1 "Text" to the status of a free-standing chapter

Definitely. It also belongs together with ...  
 
> ~ subsection 8.4.8 "Selecting notation font size";

... which is relevant, in my experience at least, when you want to
change the size of the whole score and have also made changes to the
pango font tree -- much more so than for changing the size of
individual notes in "contemporary notation" (then again, I don't write
contemporary scores).
So perhaps a unified section on "Fonts and sizes"?

I would also say -- although this may exceed the limits of what kind
of suggestions were allowed -- that one thing that is missing is a
comprehensive survey of the syntax of Lilypond. Now, it's all there,
I'm sure, but there is a huge gap between the "First Steps" section,
giving the beginner just enough information at the time to avoid
overflow, and the "Interfaces for Programmers" section, which is
intimidating, not only because it's complex, but also because of the
language: one is likely to think: "Hey, I'm not a programmer, I hardly
know what 'interface' means -- this section is not for me", which is
wrong, because that chapter contains information that anyone is likely
to need some day if one writes things more advanced than single melody
lines.
In the gap between these two extremes -- which means the rest of the
manual -- I'm sure everything one needs to know can be found, but I'd
welcome a separate section "Lilypond syntax", which would briefly but
exactly list and explain the syntax, from the file structure (which
also belongs here) down to typographical requirements (escapes, space
around { } , naming conventions for various types of objects
(Music expressions, GROBs and Contexts with CamelCase, Music classes, music
properties, Grob interfaces, and backend properties use scheme-type,
Engravers: Caps_and_underscores, and Context properties use
lowercaseAndCamelCase). 

This would be very helpful, I think.

Eyolf

-- 
Aliquid melius quam pessimum optimum non est.