Peter Toye <lilyp...@ptoye.com> 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 <lilyp...@ptoye.com> 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
