Re: Naming _another_ lacking puzzle piece

[Phil Holmes]

----- Original Message ----- 
From: "Carl Sorensen" <address@hidden>
To: "David Kastrup" <address@hidden>; "Trevor Daniels" <address@hidden>
Cc: <address@hidden>
Sent: Sunday, October 14, 2012 3:28 PM
Subject: Re: Naming _another_ lacking puzzle piece


> 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.

I've read David's reply, but am (like Janek) commenting on the principle of 
how I believe Lily should work, not how immediately possible it will be.

> 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.

I think this would be a most excellent improvement to usability, if it can 
be done.  I really think both these would be great.  In Janek's words:

+10000000000

> /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.

I hate these namings.  I still struggle with grob, and any musician would 
think we've gone nuts.  I'm not over-happy with oneMoment.  I actually think 
/once works well.  As for /tweak: I think tweak is better than oneGrob, and 
can't think of an improvement at this time.

--
Phil Holmes