Re: Issue 2047 in lilypond: Patch: Add \accidentalStyle command

[David Kastrup]

"address@hidden" <address@hidden> writes:

> On Nov 23, 2011, at 8:09 AM, address@hidden wrote:
>
>> 
>> Comment #9 on issue 2047 by address@hidden: Patch: Add \accidentalStyle 
>> command
>> http://code.google.com/p/lilypond/issues/detail?id=2047
>> 
>> Tsk tsk tsk.  Currently working on the documention, and it is rather
>> stupid that we have \accidentalStyle "default" but
>> $(set-accidental-style "default" 'GrandStaff).  I lean towards
>> allowing _only_ strings as accidentalStyle (currently
>> accidentalStyle #'default is working) and instead take an optional
>> symbol argument, like
>> \accidentalStyle #'GrandStaff "default".  At the time the command is
>> executed, I can't use ly:context-find for reliably distinguishing
>> context symbols from others.
>> 
>> When I manage getting assignments into arguments, \accidentalStyle
>> GrandStaff = #'default would be nice, but I don't yet have a good
>> workable plan for that.
>> 
>> People ok with reserving symbols for context specification, allowing
>> only strings for style spec?
>
> I'm the last person to have the right to make any claims about how to
> do UI

For user interface questions, there is no such thing as being
underqualified...

> but, that said, here I go.  Currently, all style-related properties
> are symbols (Flag #'style, etc.).  Insofar as this is a context
> modification, I realize that the syntax has to be different, but it
> may be strange to users to remember this one exception.

It isn't a context modification, but rather a property setting command
to be used within music (after another of my patches goes through, you
can use it via \settingsFrom to create a context mod, but that's quite
orthogonal to the current UI issue).

Your objection seems reasonable.  If it had been raised somewhat
earlier, it might have made me think about using a different convertrule
(the source tree is currently full of \accidentalStyle "whatever").

On the other hand, this is not a directly specified form of a property
setting command (like \set, \override), and commands like \bar, \clef,
\instrumentSwitch, \language don't take symbols, but strings.

So this does not seem like an iron-clad rule.

> Unfortunately, I can't think of a good workaround, but I figured I'd
> raise that issue.

Well, hmph.  I'd want to avoid introducing a differently-named command
for also specifying the context to use.

-- 
David Kastrup