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

[David Kastrup]

Keith OHara <address@hidden> writes:

> 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.)

Correct.  I am not particularly happy with that sort of context
dependency.  If we ever get into the situation that convert-ly needs to
tell both apart, one would likely try going via the upper/lower-case
route in the respective patterns.  But in most cases, a "path" should be
treatable as a single entity, with only LilyPond itself being required
to actually tell the difference.

> 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.

Huh, I'd not have expected a net slowdown.  Were you using the version
_after_ running convert-ly, or are we talking about "compatibility mode"
where the #' syntax is still being employed everywhere?  In the latter
case, we call the Scheme reader just as often and also have to check for
symbol properties.  In the former case, I would have expected the
savings from not calling the Scheme reader to more than compensate.

> 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.

I don't think that this is actually making a difference with regard to
"unification".  Grobs are conceptually just context properties (and
would be completely so after unification), and there is no situation
where both context name as well as grob name would be optional.

So I don't think that it will get either harder or easier.

-- 
David Kastrup