lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Quit [now definitely O/T]


From: Kieren MacMillan
Subject: Re: Quit [now definitely O/T]
Date: Wed, 11 Nov 2009 14:33:44 -0500

Hi David,

[By the way, since it's apparently open season on posting style criticism: your consistent lack of salutation and valediction in your posts makes you seem rude, curt, and above all patronizing.]

"Reasonable" entails a collective effort not to repeat avoidable work and frustration.

e.g., the GDP and the 000s of hours Graham P personally has put in to improving the docs...?

presumably _is_ something like coding style

c.f. <http://lilypond.org/doc/v2.13/Documentation/contributor/Code- style#Code-style> What needs to be added/improved? Once again, I'm sincerely asking, since you obviously still have questions about Lilypond coding style that weren't answered by that page (and surrounding ones).

or idea behind Lilypond

c.f.
<http://lilypond.org/doc/v2.13/Documentation/contributor/Overview- of-LilyPond-architecture#Overview-of-LilyPond-architecture>
  <http://lilypond.org/web/images/thesis-erik-sandberg.pdf>
Same question as above.

The internals documentation should likely spell out the layers of C+ +, Scheme, Music
macros and what one can hope to reasonably implement in what layer.
What new functionality requires equivalence of new
engravers or performers, can one implement them in Scheme, does one need
C++, and what exactly does one _do_ when creating them?

The introductory page
<http://lilypond.org/doc/v2.13/Documentation/contributor/Overview- of-LilyPond-architecture#Overview-of-LilyPond-architecture>
does spell this out, I believe.

Cheers,
Kieren.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]