Re: possibility of merging \override and \set (was: Naming _another_ lacking puzzle piece)

[Janek Warchoł]

Sorry, Reinhold - forgot to send to all..

On Sun, Oct 14, 2012 at 6:18 PM, Reinhold Kainhofer
<address@hidden> wrote:
> On 14/10/2012 17:46, Janek Warchoł wrote:
>> As for (2), i see that there are three operations that can be
>> performed on stack: push, pop and clear.
>
> Please, can we get away from thinking in terms of implementation details
> and instead think of the use cases:
>
> 1) Just set a property (grob or context property) to a certain value,
> don't worry about previous values
> 2) Set a property to the defaults
> 3) Temporarily set a property to a new value, being able to switch back
> after a while
> 4) Switch back to a previous value

ok, but do we *need* separate commands to do 1) and 3)?  To me it
seems that one command could do both; the difference between
"temporarily or not" would be in the commands used for going back,
i.e. 2) and 4).

For me, 2) is a case of "going back".  I.e. i don't think in terms of
"setting property to default value" but rather "going back to
property's default value".
"Setting property to default value" sounds to me like calling another
override, with the value just like the default value

> My suggestion for the functions performing those four basic operations are:
>
> 1) \set    (most current uses of \override by users are really meant as
> \set)
> 2) \clear (replaces current \unset, some of the \revert calls)
> 3) \override  (only needed when you need to switch back to previous value)
> 4) \restore

As i said, i don't see why we need to have both \set and \override -
for me the difference would be in \clear and \restore.  Maybe i'm
overlooking something?

Janke

PS David, i read your message that merging \set and \override will
require much more work.  I continue the discussion not because i
disregard your opinion and your work - i just think that since the
discussion is already happening, i think we might as well decide now.