Re: How to procede with \override/\revert business

[Keith OHara]

Trevor Daniels <t.daniels <at> treda.co.uk> writes:

> David Kastrup wrote Sunday, October 28, 2012 4:34 PM
> 
> > <URL:http://code.google.com/p/lilypond/issues/detail?id=2934>.
> > 
> > If we are going through with this one, it means that the
> > override/revert/overrideProperty syntax presented to users is
> > fundamentally different from before.
> 
> I think this is a price worth paying to gain the easier syntax.
> It's hard for long-standing users, but we need to look ahead
> and consider the (hopefully larger number of) future users.
> For them it will be far easier to understand (although we'll
> need to rename X-offset and friends to simplify the documentation.)
> 

It all looks good to me.  I was worried a bit that having a dot instead 
of a space between the required parts of an override would leave us 
confused when trying to adapt an unfamiliar construction in the manual:
   \override Baillithe.Gas.U-airde = #3
But now I think that, by the time anybody would be copying this from 
the manual, he has figured out the terms for the height (airde) of a 
stem (gas) and would naturally understand that 
    \override Gas.U-airde = #3      % makes sense
    \override Baillithe.Gas = #3    % is nonsense

LilyPond doesn't understand the meanings of the words, so David has 
the parser searching the data structure initialized by define-grobs.scm
to learn whether Baillithe or Gas is a grob.  (Presumably Gas would be
defined therein, if LilyPond were to use Irish as the input language.)

I timed LilyPond setting the percussion parts of a symphony, where she 
has to read all the instruments' parts to set a few cue notes.  I figure
this is a realistic example where a slower parser might be noticed.
The latest dev/syntax is only 1% slower than a checkout from before the 
first syntax change on this topic.

Testing with various typos and simulated-misunderstanding of the syntax, 
I always got a reasonable warning.  The messages pointed to the troublesome 
point in my input, which makes things pretty clear all by itself.

Unifying \override and \set seems harder now.  In
  \set MarkLine.fontSize = #-3
the use of \set tells LilyPond that there will be no Grob involved, but in
  \override MarkLine.fontSize = #-3
LilyPond will probably worry that she can find no Grob definition for 
MarkLine, because MarkLine is a context I define later, in my layout{} block.