[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Kastrup
Subject: Re: Issue 2047 in lilypond: Patch: Add \accidentalStyle command
Date: Wed, 23 Nov 2011 12:24:05 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux)

"Trevor Daniels" <address@hidden> writes:

> David Kastrup wrote Wednesday, November 23, 2011 9:11 AM
>> "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.
>>>> People ok with reserving symbols for context specification,
>>>> allowing
>>>> only strings for style spec?
>>> I realize that the syntax has to be different, but it
>>> may be strange to users to remember this one exception.
>> 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.
> As far as the UI is concerned the key consideration
> is whether the rules which define when #, $, ' and
> " should be used can be stated clearly and simply
> in a way which can be understood by a user who is
> unfamiliar with computer science terms.  If they can
> be stated more clearly with this change then I'm in
> favour of it.

I would be lying if I claimed to believe this particular decision to be
a step in either direction.

Lilypond uses symbols in quite a few situations, and it has no "native"
syntax for it.  Instead you call them using #'symbolname.  I have
considered making a,b,c,d a list of symbols (could be handy on the
command line), but in a document as opposed to the command line, not
putting a space after "," would be ugly, and then we still don't have a
syntax for single symbols.

I don't see consistency or a recognizable scheme lurking around the

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]