Re: VerticalAlignment in PianoStaff

[Mats Bengtsson]

> Here:
> 
> http://www.lilypond.org/development/Documentation/user/out-www/lilypond/Vertical-spacing.html#Vertical%20spacing
> 
> I read:
> 
> ... If you want to override this, use a
> \translator block as follows:
> 
> ...
> 
> Great! But I can't figure out where to put the code... Asumed it was just
> after my \context PianoStaff but that gives me an "error: parse error,
> expecting `STRING':" on the "{" in the above code.
> 
> Newbies like me really need to see stuff in context to get the big
> picture, so is someone could post a working .ly with VertivalAlignment *in
> PianoStaff*, that would be extremely helpful.

I understand your point of view. Still, it would make the manual
three times as big if we added a full detailed example of each
feature in the manual. 

The only reasonable solution is to describe the general principles
of how to modify the layout and make it easy to find this information.
At the moment, the "Fine tuning a piece" section of the Tutorial or 
the "Tuning output" section of the Reference manual don't even
mention the possibility of setting properties globally in the
\paper section. 

What Atte could have done in this case was to look in the
Index of the manual and find an entry 
"translator definition: Changing context definitions" which
describes the general principles, but I don't think that's
obvious. Of course, another good source of information is
the "Input snippets" document.

What we really should have is something like the following
picture over different possibilities:

- General change for all the score: Set in the paper block
- Change for a short duration and/or single line: \property ...
- Change an object that's already created: \outputproperty ...
- ???: \apply a Scheme function.

Another aspect of the documentation: Do we really need the
invented word 'grob'? Wouldn't 'object' work well in most
situations? It would clearly simplify for the average reader.
It could still be a useful concept in the source code but
for the documentation it'd be better to write out 'graphical
object' in full in the few situations where they could be
confused with non-graphical objects.

   /Mats