Re: \set vs \override

[David Kastrup]

Mats Bengtsson <address@hidden> writes:

>> Joe Neeman wrote:
>>> On Sat, 2009-11-21 at 22:45 +0000, Graham Percival wrote:
>>>   
>>>> On Sat, Nov 21, 2009 at 11:31:40PM +0100, David Kastrup wrote:
>>>>     
>>>>> I don't see a good rationale why \set, \override, \revert, \tweak should
>>>>> not work on the same set of properties (including subproperties).  I
>>>>> don't see an explanation why it makes sense to differentiate between
>>>>> them.
>>>>>       
>>>> I can't speak to the programming side of things, but as an
>>>> (ex-)user, documentation editor, and upcoming GLISS manager, I
>>>> would *love* it if we could condense these commands into a single
>>>> one.
>>>> (wrapping the revert into something like
>>>>   \override Slur #'direction = #'revert
>>>> although we'd probably want to choose a different \command to
>>>> avoid confusion with the old syntax.)
>>>>
>>>> However, I'm not at all certain that this would be an easy (or
>>>> even possible) change.
>>>
>>> It would certainly be possible, but I think it would be a bad
>>> idea. I think that having two separate commands is much clearer than
>>> having a command with two distinct behaviours depending on what its
>>> argument is.
>
> We used to have the same command for setting both context and object
> properties, see
> http://lilypond.org/doc/v2.2/Documentation/topdocs/out-www/NEWS.html

I read

    The syntax for setting properties has been simplified: the following
    table lists the differences:

                    (old)                           (new)

              \property A.B = #C                \set A.B = #C
              \property A.B \unset              \unset A.B
              \property A.B \set #C = #D        \override A.B #C = #D
              \property A.B \override #C = #D   (removed)
              \property A.B \revert #C          \revert A.B #C
     
There is no differentiation between "context" and "object" properties
here.

> If you want to bring this issue up again, don't forget to read the
> discussions that lead to the current syntax.

I am not complaining about the syntax: I find all of the commands
introduced in the above news entry sensible and with a purpose of their
own.  What I don't get is why, apparently afterwards, it has been
declared that one half of the commands is to be used only for one set of
properties, and the other for the other.

_That_ does not make sense to the user.  Because the different semantics
of those commands are not related at the user level to the different
sets of properties that you _now_ are supposed to be using them for,
respectively.

And the difference apparently is hard enough to explain that I don't
consider the information I have now sufficient.

And we are talking about _user_ level commands here.  I've been told
that I am probably among the 10 top active experts with Lilypond syntax.
While I refuse to believe this, there is enough substance to the
statement that it is a bad idea if this evades my understanding.

I have no doubt that in a few days of research I might get what led to
that decision.  And if I try to change the code accordingly, I'll likely
run into problems.  Technical problems.

If those technical problems are completely unsurmountable also
conceptually, then it means that the command names and concepts should
be changed to reflect the fundamental differences in those properties.

I don't believe this yet.

I'll try finding pointers about past discussions, yes.  But you can't
expect every user to do the same.

-- 
David Kastrup