Add scriptExceptions property/convenience functions

Add scriptExceptions property/convenience functions

These is currently no convenient way to change default
settings for a specific articulation-type.

 -- This commit adds a new context property, scriptExceptions,
which holds custom user settings to modify the default
scriptDefinitions.  The data structure is modeled after
scriptDefinitions and the public variable
default-script-alist.

The settings in scriptExceptions are simply added to the
head of the property-value alists of the indicated scripts.
New settings will be used by virtue of appearing before the
default settings, and there is no need to include settings
of untouched properties because the defaults are still present.

 -- Add two convenience functions for easily modifying settings
for a single articulation type: \addScriptExceptions and
\removeScriptExceptions

 -- Add two regtests and a Changes entry.

[david.nalesnik, 2017-04-05 00:55:51]

I've noticed that setting some properties with this patch doesn't have an
effect: for example, rotation and staff-padding.

Is the best way to approach this issue through the tweak method linked to in the
description on the issue tracker?

[carl_sorensen, 2017-04-05 03:51:02]

LGTM.

THis looks like a real handy tool for creating style sheets.

Thanks,

Carl

[pkx166h, 2017-04-05 15:47:19]

Do you want this tested? 

I cannot see any tracker issue for this.

Or is this just some work-in-progress design before you have a patch for testing
proper?

James

[david.nalesnik, 2017-04-05 15:55:38]

On 2017/04/05 15:47:19, pkx166h wrote:
> Do you want this tested? 
> 
> I cannot see any tracker issue for this.
> 
> Or is this just some work-in-progress design before you have a patch for
testing
> proper?
> 
> James

It's associated with Issue 4276.

It would be great if you could test this.

I do think that some discussion is in order over the relative merits of this
context-property approach vs. the tweaking approach linked to in the description
of 4276.

Thanks!

[dak, 2017-04-07 17:30:25]

On 2017/04/05 15:55:38, david.nalesnik wrote:
> On 2017/04/05 15:47:19, pkx166h wrote:
> > Do you want this tested? 
> > 
> > I cannot see any tracker issue for this.
> > 
> > Or is this just some work-in-progress design before you have a patch for
> testing
> > proper?
> > 
> > James
> 
> It's associated with Issue 4276.
> 
> It would be great if you could test this.
> 
> I do think that some discussion is in order over the relative merits of this
> context-property approach vs. the tweaking approach linked to in the
description
> of 4276.
> 
> Thanks!

My personal take on this would be to allow overriding, say, \override
Script.accent.padding = #2.0 .  And maybe that's where all of the script
definitions should be in the first place.

[david.nalesnik, 2017-04-07 18:27:25]

On 2017/04/07 17:30:25, dak wrote:
> On 2017/04/05 15:55:38, david.nalesnik wrote:
> > On 2017/04/05 15:47:19, pkx166h wrote:
> > > Do you want this tested? 
> > > 
> > > I cannot see any tracker issue for this.
> > > 
> > > Or is this just some work-in-progress design before you have a patch for
> > testing
> > > proper?
> > > 
> > > James
> > 
> > It's associated with Issue 4276.
> > 
> > It would be great if you could test this.
> > 
> > I do think that some discussion is in order over the relative merits of this
> > context-property approach vs. the tweaking approach linked to in the
> description
> > of 4276.
> > 
> > Thanks!
> 
> My personal take on this would be to allow overriding, say, \override
> Script.accent.padding = #2.0 .  And maybe that's where all of the script
> definitions should be in the first place.

Yes, I've considered just this syntax and believe it would be best.

The context-property method breaks down because of the way
create_script_from_event in lily/script-engraver.cc negotiates between
properties listed in scriptDefinitions (or, by extension, in the property
scriptExceptions added by the patch) on the one hand, and properties from the
grob-definition of Script/possibly introduced by user overrides on the other.

The user expectation would be that any property they put in scriptExceptions
should have an effect, but that's not the case because of the fragile way
create_script_from_event creates its property lists.  Values for 'staff-padding
are thrown out, because the value in the grob-description of Script (0.15) is an
acceptable value (ly:dimension?).  Values for 'rotation are also thrown out --
here because the default value is unset, meaning '(), which is an acceptable
value for 'rotation because the property takes a list!

I see no way to make a context property holding exceptions work with the system
in place.  (Which is why I set the patch to needs work.)

I'll work on putting an override system in place.

[dak, 2017-04-07 18:55:15]

On 2017/04/07 18:27:25, david.nalesnik wrote:

> I see no way to make a context property holding exceptions work with the
system
> in place.  (Which is why I set the patch to needs work.)
> 
> I'll work on putting an override system in place.

Ugh.  I actually don't have all that good of an idea just which override should
override what in what situation.  The user will likely expect his last override
to make a difference, but when expections and base grob are in different data
structures, "last" cannot be determined.