Re: stepping down as project manager

[James]

Hello,

On 14 October 2012 07:39, David Kastrup <address@hidden> wrote:
> Reinhold Kainhofer <address@hidden> writes:
>
>> On 2012-10-13 23:44, David Kastrup wrote:
>>> \once creates a one-time-step temporary change, \temporary an
>>> unterminated temporary change which can be terminated element-wise with
>>> \revert
>>
>> +1
>> That's a consistent naming scheme, and \temporary is a perfect match
>> with \once, so I'm all for that name. \once changes the value for one
>> step, \temporary until it is explicitly \revert'ed (und unfortunately
>> \override alone permanantly overwrites rather than overrides).
>
> It is so that \override ... \override ... \override ... \revert gets
> back to the initial state (though with a net pop, so you better start
> out on an empty stack).  Those overrides can come in packages, like
>
> \voiceOne ... \voiceTwo ... \voiceOne ... \oneVoice
>
> and many of those packages are designed to be used in a non-stack-like
> manner, presumably because some of them contain a mixture of overrides
> and reverts and/or Han-Wen had given up on teaching people about popping
> everything they pushed.
>
> If you want the above to return to its original state even in case of a
> non-empty stack, it turns out that writing \temporary before the first
> \voiceOne will do the trick, but that requires the knowledge that those
> commands are organized as a matched set.  The safe/blackbox way to do it
> would be to \temporary every \voiceXXX command, and afterwards \undo it,
> and that presumably was the original design.
>
> It apparently (as I said, this was done in an only loosely related large
> 2005 commit without comments, without mention in the log files and
> commit messages and apparently without preceding discussion) was changed
> after it turned out that users were not coping well with stacks.

That is probably the most coherent explanation I have had of this
whole thread :) thanks.

As a normal user I think a \revert should turn off (i.e. I'd expect it
go back to default) and was trying to think of a way to say this in an
email myself, but then wondered what happened in the case of all those
'functions' in the ly/directory where multiple overrides and reverts
would make this complex and give unexpected results.

I think users, if explained with good examples, would get the 'pop'
and 'push' concept but I also agree that this is too complex for
_most_ LP users to have to think about (if not understand).

>
> The current semantics are basically non-stack, but the stack can be
> reanimated temporarily from the Scheme layer.
>
> This reanimation makes sense from the user layer in some cases as well,
> particularly when we are talking about "programming" in LilyPond
> (writing reusable parts), something which was considered more of an
> oddity/curiosity in 2005 than it is now.

Yes :) and I am also guessing that those that use these features are
the most vocal on the list precisely because they understand what they
are doing when they use these 'fancy-shmancy' gymnastics within their
music; (me? I just cut and paste stuff again and give it a new $name,
this leads to much less 'thinking' and more importantly for me, admin
work when I go back to a piece of work and wonder at my own impressive
LilyPond skills that I have now forgotten) oh and means if I really
make a mess with an edit it is much easier for me to fix it. Which
leads on to:

>
> So based on the assumption that Han-Wen's stealthy change was due to a
> stack having shown itself to be too complex for "normal (TM)" users, it
> makes sense to structure the documentation for \temporary/undo in
> relation to the basic \override/revert such that the user is comfortable
> _not_ being familiar with them while at the same time having access to
> the advanced information should he ever need it.  It is not a must-learn
> item, but a good-to-know-occasionally one.

So I don't see any harm in keeping it simple in the Learning Manual
but 'getting down and dirty' technically in the NR with an @ref back
to the LM.

James