lilypond-devel
[Top][All Lists]
Advanced

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

Re: possibility of merging \override and \set


From: David Kastrup
Subject: Re: possibility of merging \override and \set
Date: Mon, 15 Oct 2012 14:32:15 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux)

"Trevor Daniels" <address@hidden> writes:

> Mats Bengtsson wrote Sunday, October 14, 2012 8:06 PM
>
>> For many years, I viewed the difference between set/unset vs. 
>> override/revert as just different command names for context properties 
>> vs. grob properties. It wasn't until David first started asking about 
>> the exact differences, that I became more aware of the other 
>> non-symmetries between the commands.

There _are_ no other non-symmetries between the commands as far as
user-accessible commands are concerned right now.  With either
\set/\unset or \override/\revert you can only achieve "stack depths" of
0 and 1: either a property is available in a context or not.

That grob properties have a convenient way to _not_ overwrite the
current value but merely mask it is a separate nicety, currently only
available to Scheme code.

>> Surely, we can 
>> have a quick introduction to the concept of stacks in the documentation 
>> (for example comparing to a deck of cards) 
>
> or maybe the stack of hot plates in the plate well of a canteen, which
> is a good example of a filo stack.  Other examples might include
> coin holders, or the way some people "organise" their in-tray ;)

Whatever analogy you dig up, if the default override command is suppose
to be push, the whole stack concept becomes a _necessary_ part for the
user to learn.  And make no mistake: stacks _are_ non-trivial programmer
concepts.

I don't think we are doing users a favor by forcing them to learn
stacks.  The current \override just overwrites the top of the stack (if
necessary, creating it first).  If you want to scare CS majors, you can
call it pop+push, but that is an implementation detail.

-- 
David Kastrup




reply via email to

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