Store accidental styles in an alist

Store accidental styles in an alist

This rewrites the way how accidental styles are stored and accessed. Previously
the two were mangled in the set-accidental-style procedure so that adding custom
styles required complete redefinition of this procedure and copying all the
existing definitions.
Now, the actual specifications of accidental styles are stored in the
'accidental-styles' alist, and the set-accidentals-properties and
set-accidental-style procedures have been replaced by a single procedure, which
reads from that alist and sets the context properties accordingly.

[simon.albrecht, 2015-12-21 19:09:21]

Sorry, first time something went wrong.

[simon.albrecht, 2015-12-21 19:18:39]

Sorry that this is such a large and convoluted patch. It had to be done this
way.
The actual functionality should be unchanged, only the structure is disentangled
and made accessible for custom additions.
In the course of action, I corrected one or two typos in comments – hope that’s
OK.

Should this get a regtest, or changes entry, or documentation? I’m not sure.

Best, Simon

[dak, 2015-12-22 14:39:59]

https://codereview.appspot.com/280510043/diff/20001/scm/music-functions.scm
File scm/music-functions.scm (right):

https://codereview.appspot.com/280510043/diff/20001/scm/music-functions.scm#n...
scm/music-functions.scm:1702: (define-public accidental-styles
The only rationale for making this a public variable is if the user is expected
to be able to change that variable.  But in that case, the settings will bleed
over into the next file on the command line if the variable is not declared
using define-session-public instead.

[simon.albrecht, 2015-12-22 21:00:58]

Use define-session-public as per David’s comment

[simon.albrecht, 2015-12-22 23:36:14]

On 22.12.2015 15:39, dak@gnu.org wrote:
>
https://codereview.appspot.com/280510043/diff/20001/scm/music-functions.scm#n...

>
> scm/music-functions.scm:1702: (define-public accidental-styles
> The only rationale for making this a public variable is if the user is
> expected to be able to change that variable.  But in that case, the
> settings will bleed over into the next file on the command line if the
> variable is not declared using define-session-public instead. 

Thanks for the hint. New patchset uploaded.
Yours, Simon

[pkx, 2015-12-23 13:52:53]

Simon,

On 22/12/15 23:36, Simon Albrecht wrote:
> On 22.12.2015 15:39, dak@gnu.org wrote:
>>
https://codereview.appspot.com/280510043/diff/20001/scm/music-functions.scm#n...
>>
>> scm/music-functions.scm:1702: (define-public accidental-styles
>> The only rationale for making this a public variable is if the user is
>> expected to be able to change that variable.  But in that case, the
>> settings will bleed over into the next file on the command line if the
>> variable is not declared using define-session-public instead. 
>
> Thanks for the hint. New patchset uploaded.
> Yours, Simon

I'm starting to lose track.

Is this a patch set that has or has not been tested?

Are you using git-cl to upload the patch - else the Allura patch level
will not change and it will not get re-tested as I filter on any
'patch-new' and 'Started' Allura issues for testing.

James

[simon.albrecht, 2015-12-23 23:48:36]

On 23.12.2015 14:52, James wrote:
> Simon,
>
> On 22/12/15 23:36, Simon Albrecht wrote:
>> On 22.12.2015 15:39, dak@gnu.org wrote:
>>>
https://codereview.appspot.com/280510043/diff/20001/scm/music-functions.scm#n...
>>>
>>> scm/music-functions.scm:1702: (define-public accidental-styles
>>> The only rationale for making this a public variable is if the user is
>>> expected to be able to change that variable.  But in that case, the
>>> settings will bleed over into the next file on the command line if the
>>> variable is not declared using define-session-public instead.
>> Thanks for the hint. New patchset uploaded.
>> Yours, Simon
> I'm starting to lose track.
>
> Is this a patch set that has or has not been tested?

It has not, at least not in the version with define-session-public (set 
3). Although this is the only change and I might assume that no extra 
testing is needed for this – I trust David that it’s fine. And perhaps 
the difference wouldn’t even be covered by testing? Dunno.

>
> Are you using git-cl to upload the patch - else the Allura patch level
> will not change and it will not get re-tested as I filter on any
> 'patch-new' and 'Started' Allura issues for testing.

Yes, I’m using git-cl and I noticed there was an error message about how 
it failed to edit Patch status in Allura. I’ll do so manually in future 
– or, Phil, can you fix this?

Yours, Simon

[pkx, 2015-12-24 09:17:34]

Simon,

On 23/12/15 23:48, Simon Albrecht wrote:
> On 23.12.2015 14:52, James wrote:
>> Simon,
>>
>> On 22/12/15 23:36, Simon Albrecht wrote:
>>> On 22.12.2015 15:39, dak@gnu.org wrote:
>>>>
https://codereview.appspot.com/280510043/diff/20001/scm/music-functions.scm#n...
>>>>
>>>>
>>>> scm/music-functions.scm:1702: (define-public accidental-styles
>>>> The only rationale for making this a public variable is if the user is
>>>> expected to be able to change that variable.  But in that case, the
>>>> settings will bleed over into the next file on the command line if the
>>>> variable is not declared using define-session-public instead.
>>> Thanks for the hint. New patchset uploaded.
>>> Yours, Simon
>> I'm starting to lose track.
>>
>> Is this a patch set that has or has not been tested?
>
> It has not, at least not in the version with define-session-public
> (set 3). Although this is the only change and I might assume that no
> extra testing is needed for this – I trust David that it’s fine. And
> perhaps the difference wouldn’t even be covered by testing? Dunno.
>
>>
>> Are you using git-cl to upload the patch - else the Allura patch level
>> will not change and it will not get re-tested as I filter on any
>> 'patch-new' and 'Started' Allura issues for testing.
>
> Yes, I’m using git-cl and I noticed there was an error message about
> how it failed to edit Patch status in Allura. I’ll do so manually in
> future – or, Phil, can you fix this?

Did you git pull recently to get the latest updates that Phil has
checked in (there have been 3 or 4 in the last month or so).

I think this issue looks like git-cl commit
a15e752cf4d42abc61b741ec8c8fafc94fe4d913 - Set updated issues to patch new

James