Re: [GLISS] turn xxx.yyy into ("xxx" "yyy")

[David Kastrup]

James <address@hidden> writes:

> On 4 October 2012 09:28, David Kastrup <address@hidden> wrote:
>>
> ..
>
>>
>> Using the symbol list form would have the advantage that
>>
>>     \override TextSpanner #'(bound-details left text) = "rit."
>>
>> could equivalently be expressed as
>>
>>     \override TextSpanner bound-details.left.text = "rit."
>>
>> and
>>
>>     \override Bottom.TextSpanner #'(bound-details left text) = "rit."
>>
>> as
>>
>>     \override Bottom.TextSpanner bound-details.left.text = "rit."
>>
>> or even
>>
>>     \override #'(Bottom TextSpanner) bound-details.left.text = "rit."
>
> I know I have cut out most of the initial email, this is deliberate
> because I just want to point out, that at least from a 'normal' user
> point of view none of them are particularly better than the other.

I did not want to imply a qualitative judgment here.  I was just
pointing out how the work on an an implementation choice allowing to
specify Bottom.TextSpanner as a music function argument led to a set of
equivalences for parts of existing constructs in a somewhat natural
manner.

> Personally I like using braces or parenthesis to separate out these
> different parts to these overrides. It is a pain (for me) to recall if
> I need to use '#'' or not but that is no different than having to
> remember if I use dots or spaces.
>
> If all you are saying is it doesn't matter which one a user picks,
> they will work, then fine, but sometimes too much choice or rather,
> too much opportunity to 'type it wrong' may lead to frustration or
> incomprehensibility if we report a technically accurate but
> hard-to-understand error message.
>
> Also, won't anyone think of the IDEs!

It is not just the IDEs.  Obviously when one departs from "established"
usage, the pattern matching facilities of convert-ly and similar get
strained as well.

In general, extensibility is bad news for all those.  I think that in
the long run, LilyPond will have to acquire MusicXML as an additional
rigid computer-readable/writeable native input language or input layer
to better facilitate using it as a typesetter for systems without native
understanding of LilyPond, similar to how PDF is a rigid file format in
the universe of PostScript interpreters.

-- 
David Kastrup