Fwd: Custom accidental styles

[Dan Eble]

[I dropped lilypond-devel when I replied.  Sending David’s reply to the list.]

From: David Kastrup <address@hidden>
Subject: Re: Custom accidental styles
Date: May 21, 2016 at 12:29:05 EDT
To: Dan Eble <address@hidden>

Dan Eble <address@hidden> writes:

>> On May 21, 2016, at 11:00 , David Kastrup <address@hidden> wrote:
>> 
>> Dan Eble <address@hidden> writes:
>> 
>>> On May 20, 2016, at 05:38 , Simon Albrecht <address@hidden> wrote:
>>>> I was hoping to do further improvements to the code (comments and
>>>> simplification) such as to make the threshold still lower, but I
>>>> didn’t get there unfortunately.
>>>> 
>>>> HTH, Simon
>>>> <accidental-style-baroque.ily>
>>> 
>>> Thank you.  That was helpful.  This worked for me:
>>> 
>>> %% Like voice, with additional cautionary cross-voice cancellations
>>> #(set! accidental-styles (append accidental-styles
>>>                       `((hymnbook-cautionary #f
>>>                          (Voice ,(make-accidental-rule 'same-octave 0))
>>>                          (Staff ,(make-accidental-rule 'same-octave 0))
>>>                          Staff))))
>> 
>> accidental-styles.hymnbook-cautionary =
>> #`(#f (Voice ,(make-accidental-rule 'same-octave 0))
>>     (Staff ,(make-accidental-rule 'same-octave 0))
>>     Staff)
> 
> It’s prettier, but it isn’t working.  With 2.19.42, I get "warning:
> unknown accidental style” and the style is not put into effect.  The
> attached file demonstrates both ways.

Ugh.  Wouldn't work with define! instead of set! either I guess (which
is what lily-lexer.cc uses effectively).  The variable is defined in a
different module (lily rather than the current lexer).

From the Guile docs:

      `define' (when it occurs at top level), `scm_define' and
   `scm_c_define' all create or set the value of a variable in the top
   level environment of the current module.  If there was not already a
   variable with the specified name belonging to the current module, but a
   similarly named variable from another module was visible through having
   been imported, the newly created variable in the current module will
   shadow the imported variable, such that the imported variable is no
   longer visible.

So for

xxx.yyy = ...

we quite likely want set! semantics.  How about for

xxx = ...

?

-- 
David Kastrup