"m...@apollinemike.com" <m...@apollinemike.com> writes: > On Nov 23, 2011, at 8:09 AM, lilyp...@googlecode.com wrote: > >> >> Comment #9 on issue 2047 by d...@gnu.org: 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 _______________________________________________ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
