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. _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user