Re: Removes ugly side bars from learning (issue 5498089)

[Phil Holmes]

----- Original Message ----- 
From: <address@hidden>
To: <address@hidden>; <address@hidden>; 
<address@hidden>; <address@hidden>; <address@hidden>
Cc: <address@hidden>; <address@hidden>
Sent: Thursday, December 29, 2011 6:01 PM
Subject: Re: Removes ugly side bars from learning (issue 5498089)


> http://codereview.appspot.com/5498089/diff/1/Documentation/learning/common-notation.itely
> File Documentation/learning/common-notation.itely (right):
>
> http://codereview.appspot.com/5498089/diff/1/Documentation/learning/common-notation.itely#newcode853
> Documentation/learning/common-notation.itely:853: <c e g>\>[ <c f a> <c
> f a> <c e g>]\! |
> On 2011/12/29 13:42:10, J_lowe wrote:
> > If we're breaking a line then should we re-state the duration.
>
> > I.e. <c e g>8\>[ <c ...
>
> I'm not too fussed about that, but the second line should be indented by
> two spaces to indicate that it's a continuation of the previous line
> (i.e. not starting its own bar).  I certainly wouldn't object to having
> an explicit duration, though!

No problem.  This isn't covered in the CG, AFAICS.

> http://codereview.appspot.com/5498089/diff/1/Documentation/learning/templates.itely
> File Documentation/learning/templates.itely (right):
>
> http://codereview.appspot.com/5498089/diff/1/Documentation/learning/templates.itely#newcode162
> Documentation/learning/templates.itely:162:
> @lilypondfile[verbatim,quote,ragged-right,texidoc,line-width=140]
> On 2011/12/29 13:42:10, J_lowe wrote:
> > Is any merit in preference to editing the snippet than forcing the
> issue in the
> > Tex code within the itely file?
>
> I'm not fond of having an explicit line-width.  Could this be done by
> either editing the snippet, or giving a papersize  option instead?
>
> I still think that it's a general bug if non-insane .ly code exceeds the
> bounds of the box, but I can't remember where we ended up in those
> bugfixes Reinhold was doing IIRC half a year ago.

It's taken me far too long to work out what's going on here.  It's our old 
friend instrument names.  Both the templates cited have material stretching 
to the right of the "page" as well as non-zero-length instrument names.  See 
http://code.google.com/p/lilypond/issues/detail?id=1691 and 
http://code.google.com/p/lilypond/issues/detail?id=766.  So it is a bug, but 
I don't think we should allow a bug to mess up what the LM looks like.  My 
suggestion is to use an explicit line-width with a comment above saying 
something like "@c Line-width is used below because of Issue 766.  If that's 
fixed, it can be removed.".  If we wait for issues like that to be fixed to 
improve the docs, we could have grotty looking docs forever...

FWIW it can be "fixed" by using papersize A6, but this leaves the example 
rather too narrow - line-width produces better looking results, since it's 
more easily adjusted.

> http://codereview.appspot.com/5498089/diff/1/Documentation/learning/tweaks.itely
> File Documentation/learning/tweaks.itely (right):
>
> http://codereview.appspot.com/5498089/diff/1/Documentation/learning/tweaks.itely#newcode4022
> Documentation/learning/tweaks.itely:4022:
> @address@hidden/LilyPond.app/Contents/Resources/share/lilypond/current/}
> Please make this an
> @example
>
> instead.  The @* syntax is really icky; I think we should only use it if
> there's no other way of getting what we want (i.e. forcing a line-break
> inside a @warning{} macro, which unfortunately does not allow normal
> line breaks).
>
> http://codereview.appspot.com/5498089/

OK - willdo.  Just think all the boxes are a bit unnecessary.

--
Phil Holmes