>> I'm a bit confused by he documentation concerning \override. In most
>> of the LR and NR it is described as a LilyPond command which changes
>> the value of a property.
>> However, it also seems to appear as a special function within a
>> \markup which adds, as opposed to changes, a property.value pair to
>> the property list (which one isn't explicitly stated, but it can
>> presumably be inferred from the context).
> What is "the property list"? What is "adds
> to"? You make it sound like
> something gets modified. It doesn't. A new list is constructed for
> passing to subordinate markup functions, a list that has some overrides
> in front while using the passed property list for its tail.
Quote from NR A.11.7 "\override": "Add the argument new-prop to the property list. " That sounds to me to be just what I said. The implementation that you describe obviously has this effect. But I think that it's different from the way that \override works outside of a \markup.
I don't think that users should have to know how things are implemented (it's interesting to me, as an ex-professional programmer, but not to the average composer/arranger) and what appears to be the dual use of aword is confusing. Hence my original post, which was, after all, only asking for confirmation about how to use oveeride, not its implementation.
>> Presumably the property value is removed from the list after the
>> markup argument has been evaluated, so there is no need for a \revert
>> command.
> There is nothing added anywhere, so nothing
> needs get "removed". The
> property lists are only passed downwards in markup functions, never
> upwards, so there would not even be a sane way of removing something.
Given the previous paragraph, I agree.
>> To sum up, am I right in thinking that within a \markup, the function
>> supersedes the command?
> The markup command takes the task of adding overrides to a markup's
> properties that are usually set up from a
> variety of sources including
> the grob properties of a grob containing
> markup, which in turn are
> initialized from the context's respective grob
> properties for this grob
> type.
I don't think this answers my question, but your previous paragraphs do.
>> I have to say, this does not feel like good program design. One does
>> not usually have two built-in operators with the same name and
>> different scopes. :)
> Well, LilyPond is not competing for a "good
> program design" prize. I
> have retrofitted some logic and coherence into
> a number of its parts in
> order to have people more confident in being
> able to work with it and
> predict its behavior. The various property
> regimes are one of the more
> complex inherited messes and fundamental to its operation. You are not
> going to fundamentally change it.
My comment did end with a smiley.
> Though being able to get rid of
> override-property eventually would be a
> good thing. That's a really ugly duckling.