lilypond-devel
[Top][All Lists]
Advanced

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

Re: RemoveEmptyStaffContext erases previous setting


From: David Kastrup
Subject: Re: RemoveEmptyStaffContext erases previous setting
Date: Sat, 13 Feb 2010 15:32:38 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.92 (gnu/linux)

Reinhold Kainhofer <address@hidden> writes:

> On Monday 08 February 2010 16:24:57 you wrote:
>> Would there be any disadvantages to replace Axis_group_engraver by
>> Hara_kiri_engraver in the default definition of Staff, and just use
>> \override VerticalAxisGroup #'remove-empty = ##t or ##f to switch
>> between ordinary and RemoveEmpty versions? Is the book-keeping
>> overhead in the Hara_kiri_engraver so large that it would increase
>> the computational time significantly or could there be any other
>> disadvantages.
>>
>> This should be a much simpler solution than trying to fiddle with
>> advanced Scheme stuff to work around limitations in the syntax.
>
> Absolutely! So, is there any reason agains using Harakiri by default?
>
>
>> I still think it's relevant to have a syntax difference between -
>> Copy the current definition of context type Foo - Take settings from
>> a variable called Foo
>
> Yes, you are right that their syntax right now looks the
> same. However, how often do you really want to store a previous state
> of a context into a variable and reset the context later on?
>
> Most of the time, you rather want to define a set of context
> modifications to be applied at a later time (like in the RESC case),
> instead of completely restoring a context. Unfortunately, this feature
> is missing from LilyPond...

If \set and \override worked on both kind of properties (by checking
what they are trying to be used on and using a corresponding
mechanism/data structure), it might be possible to push context
modifications into an \override list.

That might solve this particular problem and might make it possible to
move some explanations about set/override differences to documentation
intended for more advanced uses.

-- 
David Kastrup





reply via email to

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