Re: Autobeaming

[David Kastrup]

Han-Wen Nienhuys <address@hidden> writes:

> On Thu, Dec 31, 2009 at 10:18 AM, Joe Neeman <address@hidden> wrote:
>
>>> > If you were to use a context property, why would you need the
>>> > special command \overrideTimeSignatureSettings to change it? That
>>> > is, why couldn't people just use \set? If it helps, we could
>>> > extend \set to allow nested properties (the same thing that
>>> > http://codereview.appspot.com/182042/show does for paper-block
>>> > variables).
>>>
>>> Because I want to be able to \revert, not just \unset.  I want to be
>>> able to change to some custom behavior, then go back to the default
>>> behavior without having to know what the default behavior is in
>>> detail.
>>>
>>> IIUC, \override is roughly equivalent to \set value (cons new-value
>>> old-value).  I want to have that functionality, so that old-value is
>>> still available for a \revert.
>>>
>>>  But certainly nested properties would help in making this change.
>>>
>>> Why have we decided that context properties can only be \set, and
>>> grob properties can only be \overridden?  In version 2.0 we had two
>>> kinds of properties, layout properties and translation
>>> properties.  I think that translation properties in those days are
>>> what we now call context properties, and that what were then called
>>> layout properties are now called grob properties.  Also, in version
>>> 2.0 we could either \set (destructively assign a value) or \override
>>> (push a value on the stack).  In fact, according to the
>>> documentation, \override and \revert were the equivalent of push and
>>> pop.
>
> This is a misconception, and the change in syntax was made to stop
> this misconception from breeding.

It didn't succeed.  I think that in this case it would make more sense
to better match the behavior to the misconception than the other way
round.

Because understanding the misconception requires technical expertise on
the level required for _changing_ the behavior, and that is a scarce
resource.

If yielding to this misconception needs two different _implementations_
of the setting commands depending on whether they are used in contexts
or grobs that is a smaller price to pay than requiring two different
user level _explanations_.

If you can save yourself the trouble of making your _users_ smarter by
instead making the _code_ smarter, that is well-invested time.

Because user stupidity is diversified and unreliable, whereas code needs
to be fixed just once.

> Of course, the \set \unset model falls apart for autoBeaming
> properties, which is exactly why have (had; do we still have it?) the
> hack that messes around with layout properties of a non-existent grob
> to store auto-beaming properties.  I don't think having nice syntax
> for auto-beam settings is worth the effort and confusion of an
> implementation of stack-like behavior for normal properties.

But the confusion _is_ there.  The documentation cannot really hope to
clear it up because there is no reason accessible from user-level for
it.

> We used to have a single namespace for properties, eg.
>
>   \property stemVerticalDirection = #UP
>
> beyond hard to maintain the zillion properties, each override would be
> stored individually in every grob, taking an acons (16 bytes) per
> grob, per formatting property, which made Peter's machine start
> trashing
>
>   git diff release/1.3.80..release/1.3.81

So now instead of Peter's _machine_ thrashing while typesetting music,
we have Paul, George and Mary (and likely Peter as well) thrashing while
trying to understand the documentation.

That's not a good deal.  Especially because implementing grob and
context properties differently does not necessitate giving them a
different user interface.

-- 
David Kastrup