lilypond-devel
[Top][All Lists]
Advanced

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

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


From: David Kastrup
Subject: Re: How to procede with \override/\revert business
Date: Mon, 29 Oct 2012 09:07:56 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

Werner LEMBERG <address@hidden> writes:

>>> there is still the big convert-to-single-path-override patch
>>> pending, how available in dev/syntax and discussed in
>>> <URL:http://code.google.com/p/lilypond/issues/detail?id=2934>.
>
> Everything looks fine!  Thanks for your efforts.  Am I right that
>
>   \override foo.bar
>
> is the same as
>
>   \override foo . bar
>
> ?  This would be quite important for formatting input files.

Yes, that's the same.  In order to make old uses of

\overrideProperty "Context.Name" ...

blend in, I also made that equivalent.  It turns out that there are
enough uses of \overrideProperty #"Context.Name" (where an explicit
Scheme string is requested and a conversion would seem inappropriate)
are around that this incentive was nonsensical.  However, this change
also makes
\override Context.Name
work in lyrics mode where it has previously been necessary to write
\override Context . Name
so I decided to keep it: the special lyricsmode behavior is a pain to
explain.  How it works now out of the box would be even more painful to
explain, but it is unlikely anybody would ask.  One can leave the
explanation in a place where a curious expert will find it, and nobody
will miss it.

There would also be some incentive to distinguish quoted and non-quoted
strings here, particularly again in lyrics mode, and only allow paths
made from unquoted strings.  The question then is whether
$"xxx"
which means "interpret the Scheme string xxx as if it was a LilyPond
identifier" or \zzz after zzz=xxx should be allowed to be converted into
identifiers.  Since zzz=xxx and zzz="xxx" are indistinguishable from the
results, it seems like making a distinction here when it is not apparent
in the data structure itself after assignment is likely going to cause
more pain than gain.

Again, this makes one wish a bit for the data model of Lua which does
not distinguish strings and symbols, instead interning every string
(which essentially is what a symbol is all about).

So yes, there is some leeway in the details that are basically judgment
calls.  I tend to think that most judgment calls were made with a good
balance between pain and gain, but if we apply the usual standards of
LilyPond development, this would call for at least two months of
bikeshedding and exasperation.

-- 
David Kastrup



reply via email to

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