Simon Albrecht <simon.albre...@mail.de> writes:
> On 28.11.2016 23:20, David Kastrup wrote:
>> Simon Albrecht <simon.albre...@mail.de> writes:
>>
>>> On 28.11.2016 23:13, David Kastrup wrote:
>>>> Simon Albrecht <simon.albre...@mail.de> writes:
>>>>
>>>>> On 28.11.2016 17:27, David Kastrup wrote:
>>>>>> Simon Albrecht <simon.albre...@mail.de> writes:
>>>>>>
>>>>>>> \version "2.19.49"
>>>>>>> %{
>>>>>>> It would be formidable if in such a case one wouldn’t need
>>>>>>> to look up the default stencil procedure, but could use either
>>>>>>> \undo or \revert.
>>>>>>> Is this a valid/sensible feature request?
>>>>>>> %}
>>>>>>> \score {
>>>>>>> \new PianoStaff \with {
>>>>>>> \omit SystemStartBrace
>>>>>>> \accepts GrandStaff
>>>>>>> } <<
>>>>>>> \new GrandStaff \with {
>>>>>>> % those don’t work
>>>>>>> %\undo\omit SystemStartBrace
>>>>>>> %\revert SystemStartBrace.stencil
>>>>>>> % this does
>>>>>>> \override SystemStartBrace.stencil =
>>>>>>> #ly:system-start-delimiter::print
>>>>>>> } <<
>>>>>>> \new Staff { 1 }
>>>>>>> \new Staff { 1 }
>>>>>>> >>
>>>>>>> \new Staff { 1 }
>>>>>>> >>
>>>>>>> }
>>>>>> The context modification for GrandStaff does not have access to the
>>>>>> unmodified definition of the enclosing PianoStaff (it doesn't even have
>>>>>> access to the unmodified definition of GrandStaff and does not know that
>>>>>> it will get applied to a GrandStaff) and even if it did, how should it
>>>>>> guess that you want to undo PianoStaff settings rather than Score
>>>>>> settings?
>>>>> OK, I’ll take that as a no. Or is it just that it would be complicated
>>>>> to implement a behaviour matching my naïve expectation?
>>>> It would be complicated to give a sensible definition of your naïve
>>>> expectation.
>>>>
>>>> If you wrote
>>>>
>>>> \undo \omit GrandStaff.SystemStartBrace
>>>>
>>>> or the equivalent
>>>>
>>>> \revert GrandStaff.SystemStartBrace.stencil
>>>>
>>>> in the music itself, you could not expect it to revert the settings of
>>>> PianoStaff . So why do you expect it do do this in the context mod ?
>>> Put another way: I want to prevent the ‘trickling down’, or inheriting
>>> of the property from the parent context. Maybe there should be a
>>> separate syntax for that?
>> That does not even make sense. Either the context has a property of its
>> own or it inherits the property. There is no third option.
>
> By default, both PianoStaff and GrandStaff print a
> SystemStartBrace. If I omit it from the outer one, the inner one has
> its also omitted, which is what I wanted to prevent. Has my wording
> been imprecise in that the _value_ is inherited?
By default, both PianoStaff and GrandStaff have the property
systemStartDelimiter set to #'SystemStartBrace .
Neither of them fiddles with the SystemStartBrace stencil: that stays at
the global default.
If you want mess with the local hierarchy, you might be better off
playing with the systemStartDelimiter setting rather than with
SystemStartBrace.stencil .
--
David Kastrup
_______________________________________________
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond
