Re: Naming _another_ lacking puzzle piece

[David Kastrup]

Carl Sorensen <address@hidden> writes:

> Two years ago, David and I had a discussion about the existence of /tweak,
> /set, and /override.  David pointed out the confusing nature of the
> different ways of changing properties, and the difficulty of explaining
> this to the user.
>
> <http://lists.gnu.org/archive/html/lilypond-devel/2010-06/msg00054.html>
>
>
> Perhaps now David has put together enough infrastructure that it is time
> to abandon the previous interface and replace it with one that will be
> more consistent to the user.

In a nutshell: no.

> IIUC, /set and /unset are currently the same as /override and /revert,
> except they apply to different things: /set and /unset to context
> properties, and /override and /revert to grob properties.  But David
> has done such good work in allowing the system to determine the target
> of a call (I suspect that with David's recent patches we have the
> infrastructure to apply the same call to both context properties and
> grob properties) that I believe we can drop the distinction.  If I'm
> wrong, please correct me, David.

You are wrong.

> Would it be possible to move to something like the following?
>
> /set modifies a property in such a way that no history is kept.
> /unset (or /reset) returns a property to its default value.
>
> /override modifies a property in such a way that a history of the change
> is stored.
> /revert undoes the most recent /override of the specified property.

The data structures for grob properties and context properties are
different (grob properties _are_ context properties but have an internal
structure of their own).

> If we want to move in this direction, I think now is the time to do it
> (before /temporary gets into the code base).

Not really.

> The reason I believe we should do it now is that without /temporary
> available, convert-ly rules could move all /override to /set and all
> /revert to /unset or /reset.  We don't need to try to parse the
> /temporary and track the items to which the /revert applies.

The effort of changing convert-ly is trivial compared to the required
changes in data structure.  The property system is on my todo list, but
this won't get current before several more months at least.  Providing
\temporary is not doing any fundamental change.

The main problem from the time you described with

> David pointed out the confusing nature of the
> different ways of changing properties, and the difficulty of explaining
> this to the user."

is that the documentation "explaining" the relation of grob properties,
context properties and other things is a ridiculous heap of fetid,
turgid...  Excuse me.

We can and must do better than that, and indeed, we are starting with
it.  At least I more or less _have_ understood the system by now, so I
can be of some help to documentation writers.

At the time of that discussion, I did not understand the system, and the
explanations were not making any more sense either.

Yes, it would be nice if all naive assumptions about the system turned
out to be true.  That's an ultimate goal, but we don't have what it
takes right now to get there.

But the next best thing is that with a good and thorough explanation,
one can figure out what's up.  And I think that we are in the situation
to work out such an explanation between someone who has a good grasp of
explaining things at a nice level, and between some technical savvy
people including myself who actually understand what is going on.

A well-presented system is not as good as a self-evidently simple
system, but it beats what we have now, and I think it is what we can do
with reasonable effort.

-- 
David Kastrup