lilypond-devel
[Top][All Lists]
Advanced

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

Re: Fixes all black bars in NR (issue 6345088)


From: graham
Subject: Re: Fixes all black bars in NR (issue 6345088)
Date: Wed, 11 Jul 2012 19:45:08 +0000

I've only looked at the first few files, but I have grave concerns with
this patch.

I feel terrible about it, though.  Please, PLEASE, anybody who wants to
make lots of changes to the docs -- spend *at most* one hour working on
your changes, then submit them to get feedback.  It must have taken a
long time to do all this, and if it doesn't get accepted this will be a
real shame.
(some parts of this patch are obviously good and could be pushed
directly, but they're all mixed in with parts that I have concerns
about, so it's problematic)


http://codereview.appspot.com/6345088/diff/1/Documentation/notation/fretted-strings.itely
File Documentation/notation/fretted-strings.itely (right):

http://codereview.appspot.com/6345088/diff/1/Documentation/notation/fretted-strings.itely#newcode1134
Documentation/notation/fretted-strings.itely:1134: The file
@file{predefined-ukulele-fretboards.ly} contains the fret
I'm not a fan of this change.  I'd rather have a manual line-break on
its own line:

... are contained in the file
@*
@file{blah}

http://codereview.appspot.com/6345088/diff/1/Documentation/notation/fretted-strings.itely#newcode1404
Documentation/notation/fretted-strings.itely:1404:
@file{ly/predefined-guitar-fretboards.ly}, @*
oh god.  Seriously?!  there _has_ to be a better way to make tex behave.

hmm, maybe these could be wrapped in an @example?  it's icky, though.
Not a serious suggestion.

http://codereview.appspot.com/6345088/diff/1/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):

http://codereview.appspot.com/6345088/diff/1/Documentation/notation/input.itely#newcode1359
Documentation/notation/input.itely:1359:
@lilypond[verbatim,papersize=a8landscape]
why is this necessary?  Does lilypond-book not select the appropriate
paper size when there's a \book{} inside the example?  If that's the
case, it should be solved with lilypond-book, not by manually changing
every @lilypond that involves \book.

(this sounds slightly familiar.  Didn't we have a round of bugfixes in
lilypond-book on this problem?)

http://codereview.appspot.com/6345088/diff/1/Documentation/notation/notation-appendices.itely
File Documentation/notation/notation-appendices.itely (right):

http://codereview.appspot.com/6345088/diff/1/Documentation/notation/notation-appendices.itely#newcode48
Documentation/notation/notation-appendices.itely:48: @c The line width
is a hack to allow space for instrument names
I really don't like seeing hacks like this in the docs; it's just
wall-papering over flaws in lilypond itself.  There should be a way to
tell lilypond "you have this much width on the page", and then lilypond
should select an appropriate line-width for the first line of the score
in order to have enough space for the instrument names.

http://codereview.appspot.com/6345088/



reply via email to

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