lilypond-user
[Top][All Lists]
Advanced

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

Re: A question about \override in markuplist


From: David Kastrup
Subject: Re: A question about \override in markuplist
Date: Fri, 29 Nov 2019 23:25:36 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

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.

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

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

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

-- 
David Kastrup



reply via email to

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