lilypond-devel
[Top][All Lists]
Advanced

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

Re: Using .ily for included lilypond files


From: David Kastrup
Subject: Re: Using .ily for included lilypond files
Date: Mon, 18 May 2009 12:16:47 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.92 (gnu/linux)

David Kastrup <address@hidden> writes:

> Francisco Vila <address@hidden> writes:
>
>> 2009/5/17 David Kastrup <address@hidden>:
>>> \notelanguage "english" { ... }
>>>
>>> which switches the parser to english language while parsing the given
>>> expression (and loads internally some .ily file once with the required
>>> information if necessary, retaining it for further switches).
>>
>> Why not
>>
>>   { \setNoteLanguage "english"
>>   ...}
>>
>> that would set the note language from now on, instead of requiring an
>> expression as argument?
>
> Sounds reasonable at first glance.  \setNoteLanguage should likely work
> at a level where Scheme macros (special forms?) work, namely right at
> the point where the parsed expression is formed, not at its execution
> time.
>
>     { \setNoteLanguage "deutsch" c d e f g a h c }
>
> should likely be completely equivalent to
>
>     { c d e f g a b c }
>
> Or something like that.

Ok, I have thought a bit more about this.  The problem with
"\setNoteLanguage" which supposedly holds until the "end of a group"
(whatever that may be) is that it still commingles execution and syntax.
Since note names are basically syntactic entities, being able to change
the syntax on the fly is just asking for trouble.  In particular if you
want to generate or interpret stuff.

I should think it saner to have the language be part of the syntax.
Namely some form of \withNoteLanguage rather than \setNoteLanguage.  And
I think it would be saner if included files would by default be in
Netherlands, unless they are explicitly included using possibly
something like

    \withNoteLanguage "deutsch" \include

(which is not likely a good idea to support at all).  That way stuff has
more of a chance to be reusable.  It would also mean that if somebody
wrote some parts in the input language he preferred, it would still
seamlessly fit into projects from others.

-- 
David Kastrup





reply via email to

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