Re: Make arguments like Context.GrobName accessible as symbol lists (issue 6635050)

[Trevor Daniels]

address@hidden: Tuesday, October 09, 2012 9:38 AM


> Here is the rub: what we are currently talking about is a choice between
> several convert-ly rules that all lead to valid programs after this
> change.
> 
> Whether you write
> \override TextSpanner #'(bound-details left stencil-align-dir-y) = #-2
> or
> \override Bottom.TextSpanner #'(bound-details left stencil-align-dir-y)
> = #-2
> or
> \override #'(Bottom TextSpanner) bound-details.left.stencil-align-dir-y
> = #-2

and presumably even
\override Voice.TextSpanner   bound-details.left.stencil-align-dir-y = #-2
(which I prefer)

> it is now all the same to LilyPond.
> 
> Now it is nice to have found underlying principles making it possible to
> obliterate fine distinctions and remove the necessity of using Scheme
> for specifying a grob property path to modify, with mostly cosmetic
> backward compatibility consequences.
> 
> But since LilyPond is now able to _read_ a lot of different phrasings of
> the same material, the question is how we want to be _writing_ this
> material.

Indeed.  We need to define a canonical form for the bulk of the manuals,
although we should explain the flexibility and available variants once.
 
> I'll likely go for the quoteless \accidentalStyle form generally here.

Good.
 
> I think I'll prepare a radical convert-ly-only patch on top of this
> patch series that demonstrates what "now valid" syntax we _could_ be
> using/advertising as input if we wanted to.

It's only right and just that you get first go at suggesting a canonical form,
and a patch would be a good way of expressing your preference.
(Regexp tutorial, anyone?  Although we can always apply the patch and 
run it on the manuals.)

> We can get rid of a _lot_ of #' style thingies with this patch series.

The more the better.

>> Let's get all the syntax changes incorporated in 2.17,
>> then we can agree an immutable set ready for release 3.
> 
> "Immutable" as "we guarantee we will be able to process this" rather
> than "we guarantee we will write our scores to have input looking like
> that"?

I meant the former; the latter would be just an aspiration.  As with 
the documentation, this will need an agreement on the canonical form.

Trevor