Re: [GLISS] delimiters, interpretation context, confusion (was: how to make decisions?)

[Janek Warchoł]

(sorry, Keith, forgot to cc the list)

On Wed, Sep 5, 2012 at 10:59 AM, Keith OHara <address@hidden> wrote:
> The broad question is: Require delimiters to clarify context (for users,
> LilyPond, and software importing LilyPond) -- more or less?

On Wed, Sep 5, 2012 at 11:54 AM, Trevor Daniels <address@hidden> wrote:
> There are many places in LilyPond now where delimiters are necessary
> to resolve certain situations but are not generally mandatory.  Perhaps
> this approach could be extended.

+1

(On Wed, Sep 5, 2012 at 10:59 AM, Keith OHara <address@hidden> wrote:)
> The broad question for these three is: Syntax that changes depending on the
> definitions of the functions in the input -- good or bad?

looks bad for me (but i'm no expert).


On Wed, Sep 5, 2012 at 11:47 AM, Keith OHara <address@hidden> wrote:
> Janek Warchoł <janek.lilypond <at> gmail.com> writes:
>
>> I think that for the next several weeks we should focus on gathering
>> information about the /problems/ people have.  Not the ideas for
>> solutions.  Problems.
>>
>> For example,
>>   "in { a \parenthesize b \mf c d } it's confusing what gets
>> parenthesized and what gets mezzoforte"
>> is a description of a problem, while  [...]
>> is a solution.  Lets talk about problems first, then solutions.
>
> I think I have that problem, but maybe not exactly what you mean.
>
> Does the confusion you refer to happen more in reading (other people's)
> Lilypond input, or in writing your own Lilypond input?

When i'm writing Lily code.  And when i'm teaching Lily to other people.


On Wed, Sep 5, 2012 at 12:37 PM, David Kastrup <address@hidden> wrote:
>
>> Keith OHara wrote:
>> I've seen complaints in non-Lilypond forums that LilyPond pitch entry is not
>> relative to key signature.  We could accommodate this by re-defining pitch
>> names upon seeing
>>   { \keyAffectingEntry \d\major  ... }
>> so that f means F-sharp and we have to type fn for F.  (This requires
>> pushing a
>> pitchname-table on a stack for every nested level of {} or <<>>)
>
> My personal take on this is "no".  Reason 1 is that then the actual
> pitch will depend on _input_ accidental rules.  That will make MIDI and
> MusicXML output less predictable.  Reason 2 is that a human-oriented
> linear non-graphic representation of what is usually seen graphically
> should resemble the manner in which humans would talk on the phone, a
> similarly linear medium.  I don't know other note language conventions,
> but here in Germany you would _never_ call a fis an f just because its
> accidental is contained in the key signature.  Totally unthinkable even
> among amateurs.  You'd immediately get "Oh, this is supposed to be an f?
> How do you tell?".  Not because of nitpicking, but because nobody would
> guess that f would be used to describe a fis.

I'd say we could have a movable do for this purpose:
\movableDo { \key d \major do re mi fa sol la si do }  ==  \key d
\major d e fis g a b cis d

Janek