Re: A question about \override in markuplist

[David Kastrup]

Peter Toye <address@hidden> writes:

> David,
>
> Thanks for this. My comments are below. My mind is much clearer now.
>
> -------------------------
> Friday, November 29, 2019, 10:25:36 PM, David Kastrup wrote:
>
>> Peter Toye <address@hidden> writes:
>
>>> 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.

It's identical to the effect of \temporary \override .

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

It does the same thing.

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

Usually a smiley applies to the preceding sentence.

>> Though being able to get rid of override-property eventually would be
>> a good thing.  That's a really ugly duckling.
>
> Agreed.

Just to avoid a misunderstanding: \override-property is brought up first
in that sentence of mine and does not in any way concern the \override
markup command \override music syntax parallel.

-- 
David Kastrup