Re: RemoveEmptyStaffContext erases previous setting

[Graham Percival]

On Sun, Jun 20, 2010 at 03:17:34PM +0100, Phil Holmes wrote:
> "Reinhold Kainhofer" <address@hidden> wrote in message  
> news:address@hidden
>> On Friday 05 February 2010 18:05:52 you wrote:
>>> On Fri, Feb 5, 2010 at 3:14 PM, Reinhold Kainhofer
>>>
>>> <address@hidden> wrote:
>>> > I found out the hard way that apparently adding > 
>>> \RemoveEmptyStaffContext
>>> > globally to a score will erase some previous settings.
>>>
>>> Yes.  \removeEmptyStaffContext copies the new context over the
>>> previous one.  Or something like this.
>>
>> Yes, it works as follows: The \removeEmptyStaffContext variable stores the
>> newly created Staff-derived context in the init file (i.e. when
>> removeEmptyStaffContext is defined, so it contains only the default  
>> settings for
>> Staff). All subsequent changes to the Staff context are of couse not  
>> applied to
>> the removeEMptyStaffContext variable.
>> When you insert RESC into your score, however, the current Staff 
>> context is
>> replaced by the value of the RESC, which does not contain any of your  
>> changes.
>>
>> So, while it is clear how things work when you know the internals, I  
>> definitely
>> regard this a bad bug, as something innocent as automatically removing  
>> empty
>> staves has lethal side-effects (e.g. on figured bass and all different  
>> unrelated
>> areas!).
>>
>> So, from a developer perspective, the current behavior might be 
>> expected, but
>> it is definitely not what any sane USER would expect. And for me this 
>> is the
>> definition of a bug.
>>
>> I think RESC should be somehow recoded to apply only the relevant 
>> changes when
>> it is actually called, but not store the whole Staff context at 
>> definition time.
>>
>> Cheers,
>> Reinhold
>
> I've had a long look at this and can confirm that there are some slightly 
> odd things going on, and variations between 2.12 and 2.13.  Please see 
> the attached image and let me have your thoughts.

Stop.  Do not pass go.  Do not ask for thoughts.

- is there a Tiny example which you believe demonstrates
  something unexpected or weird, using the latest development
  version?

If yes, add it to the tracker.  Period.  umm, after checking to
see if it's already in the tracker.  Period-period.


My only concern here is that you're using 2.13.21, and I have a
vague feeling that I've seen some bugfixes about removeEmpty
stuff.  It's slightly possible that this behaviour isn't present
in 2.13.24-2.  But if it _is_, dump it in the tracker.

You don't need to care if it's a problem in RemoveEmpty, a problem
in the figured notation, or a problem somewhere else.  You don't
even need to care if it's a problem in the docs vs. code (guessing
is fine; spend less than 30 seconds pondering the Type).


now, as it happens in this case, Reinhold's posted a great
explanation of why it's happening; you should copy&paste that into
the tracker issue.  Type-Defect, Priority-Medium.  No, it doesn't
look like a regression in anything that worked deliberately in the
past.

Cheers,
- Graham