lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Make arguments like Context.GrobName accessible as symbol lists (iss


From: dak
Subject: Re: Make arguments like Context.GrobName accessible as symbol lists (issue 6635050)
Date: Tue, 09 Oct 2012 08:38:34 +0000

On 2012/10/09 08:14:55, t.daniels_treda.co.uk wrote:
<address@hidden>: Tuesday, October 09, 2012 8:36 AM

> so I'd crank open another convert-ly rule to turn those into
> \accidentalStyle piano-cautionary
> as well.  Which makes for worse backward-compatibility of scores.
>
> What do people prefer to see?

As the 2.17 releases appear to be majoring on syntax changes I'd
prefer
to go for the most intuitive easily-learned syntax rather than
backward
compatibility.

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

I'll likely go for the quoteless \accidentalStyle form generally here.

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.

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

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"?

http://codereview.appspot.com/6635050/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]