What do people think about the doc reorg shown in:
http://kainhofer.com/~lilypond/Documentation/general/Manuals.html
(and the actual manual pages, of course)
I think I have the balance between Learning and Usage good now.
The only remaining issues are:
1) Learning B. Scheme tutorial -- do we
+1.
(I've always felt this way, too.)
Trevor (B).
On Thu, Sep 24, 2009 at 5:44 PM, Werner LEMBERG w...@gnu.org wrote:
What's the reason that line breaks are by default forbidden if there
is a broken beam crossing the bar line, and that you have to set the
`breakable' flag manually to
What's the reason that line breaks are by default forbidden if
there is a broken beam crossing the bar line, and that you have to
set the `breakable' flag manually to override it?
BTW, it is very unpleasant that lilypond doesn't emit any kind of
warning if it produces an overlong staff
Werner LEMBERG w...@gnu.org writes:
What's the reason that line breaks are by default forbidden if
there is a broken beam crossing the bar line, and that you have to
set the `breakable' flag manually to override it?
BTW, it is very unpleasant that lilypond doesn't emit any kind of
warning
On 9/27/09 6:57 AM, Graham Percival gra...@percival-music.ca wrote:
What do people think about the doc reorg shown in:
http://kainhofer.com/~lilypond/Documentation/general/Manuals.html
(and the actual manual pages, of course)
I think I have the balance between Learning and Usage good
On Sun, Sep 27, 2009 at 10:15:30AM -0600, Carl Sorensen wrote:
On 9/27/09 6:57 AM, Graham Percival gra...@percival-music.ca wrote:
1) Learning B. Scheme tutorial -- do we want to keep this here, or
integrate into Learning 4? Or _possibly_ make a Learning 5
Programming inside LilyPond?
Le dimanche 27 septembre 2009 à 17:37 +0100, Graham Percival a écrit :
How much of scheme do we get into, though? I mean, what about
moving it back into Notation?
This would be wrong: even if we expanded it up to make a big chapter, it
would not become reference documentation (we alreadhy have
On Sun, Sep 27, 2009 at 07:55:32PM +0200, John Mandereau wrote:
Le dimanche 27 septembre 2009 à 17:37 +0100, Graham Percival a écrit :
As far as I'm concerned, as long as newbies know that it's
*possible* to do all sorts of funky stuff with this magical scheme
stuff, that's all they need to
Le dimanche 27 septembre 2009 à 13:57 +0100, Graham Percival a écrit :
What do people think about the doc reorg shown in:
http://kainhofer.com/~lilypond/Documentation/general/Manuals.html
(and the actual manual pages, of course)
I think the frame Read it now is superfluous, a simple link Read
Le dimanche 27 septembre 2009 à 19:08 +0100, Graham Percival a écrit :
I'm wondering if we can call them Function index and Concept
index. Or something like that. It just seems weird to have a
LilyPond index for every manual.
Maybe Function and concept index, as this index actually merges
Hi,
I'm looking at this in terms of design inconsistencies rather than
documentation issues.
I've been looking around at the code and documentation regarding
contexts and noted these statements:
LM 3.3.2 says
Note that there is no |\new Score| command;
*the single top-level |Score|
Some, but not all of the functions declared in context-property.cc are
declared as methods of the Context class in context.hh. Is this by
design or is it an oversight?
Declared in both are:
apply_property_operations
execute_revert_property
execute_pushpop_property
On 9/27/09 11:55 AM, John Mandereau john.mander...@gmail.com wrote:
Le dimanche 27 septembre 2009 à 17:37 +0100, Graham Percival a écrit :
How much of scheme do we get into, though? I mean, what about
moving it back into Notation?
This would be wrong: even if we expanded it up to make a
13 matches
Mail list logo
