Re: stemNeutral problem

[David Kastrup]

David Kastrup <address@hidden> writes:

> Edward Neeman <address@hidden> writes:
>
>> Hello,
>>
>> I’ve come across some weird behaviour from the \stemNeutral command. This 
>> doesn’t work:
>>
>> %%%%
>>
>> \version "2.19.82"
>>
>> \relative {  \stemUp <g' bes d>8) r8
>>      \acciaccatura { \stemDown <ges' bes>8 } \stemUp <c e g!> r
>>     \stemNeutral c,16 es ges bes }
>>
>> %%%
>>
>> Adding a second \stemNeutral command is necessary to reset the stems to 
>> normal. Why might this be?
>
> Here is the deal.  \acciaccatura does an implicit \temporary \stemUp (as
> that's a default for grace notes) which it cancels at the end of
> \acciacatura, provided that it is still active.
>
> \stemDown will cancel this preexisting \temporary \stemUp.
> Consequently, \acciacatura does not see the preexisting \temporary
> \stemUp at its end any more and will do nothing, in effect leaving a
> \temporary \stemDown on the stack.  Your next \stemUp will replace it
> with a \temporary \stemUp which will get canceled by \stemNeutral,
> making the original \stemUp surface.
>
> Ugh.  The solution is to cancel your \stemDown yourself, using
> \stemNeutral .
>
> Now let's assume that \acciaccatura would not do that kind of "matched
> pop" at its end and would remove the \stemDown.  Now if you write
> \acciaccatura { \stemNeutral ... } this would pop the _preceding_
> \stemUp which would be even worse.  And was the reason the current
> behavior was implemented.
>
> So maybe the "matched pop" should be done in a different manner: if the
> previous state of the stack can be restored, do so, without actually
> looking at what you are going to pop in order to get there.

The "matched pop" is also used for \once \override .  If you write
something like

\stemDown \once \stemUp \stemNeutral

what's the expectation for the current timestep, and what's the
expectation for afterwards?

In short, this is sort-of a messy area.  It's not necessarily the best
way \acciaccatura works but the premise is that the behavior for its
private overrides is similar to \once \override and either try not to
tamper with stuff they don't understand because then the effects are
"non-local".

Maybe the understanding could be extended beyond where it is now but it
would require some refactoring: the current implementation delivers a
"pop token" at negligible cost, and so there are no separate
implementations for when it is actually needed and not.  For a slightly
better "pop token" like sketched above, there would be non-trivial
cost.  I am not sure it would work all that much better.

-- 
David Kastrup