Re: Naming _another_ lacking puzzle piece

[Carl Sorensen]

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.

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.

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.

/oneMoment (equivalent to /once, but perhaps a more clear name) modifies a
property in the current context for one musical moment.  Once the musical
moment has passed, the changes introduced by the /oneMoment evaporate.  We
could apply /oneMoment as a modifier to either /set or /override, or we
could just allow it to stand on its own.  There is no difference between
/oneMoment /set and /oneMoment /override, since the changes evaporate once
the moment is gone, so we might as well just to /oneMoment, I think.

/oneGrob modifies a property for a single grob (equivalent to /tweak).
Its effects are limited to a single graphical object, rather than all
objects occurring in this context at this time.

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

Thanks,

Carl