2009/11/24 David Kastrup <d...@gnu.org>
>
> > file3.ly:
> > myInclude =
> > #(define-music-function (parser location file) (string?)
> > #{ \include $file #}
> > (make-music 'void #t))
> >
> > \myInclude "file2.ly"
> > \markup \foo
>
Please ignore this case, it's broken. What I had in mind a bit more complex,
and probably does not really matter.
The two important points to keep in mind are:
1) user defined commands shall not pollute the internal modules
When file1.ly e.g. redefines a builtin command, it shall not change the
behavior of other file compilation:
lilypond file1.ly file2.ly
shall give the same result as:
lilypond file1.ly
lilypond file2.ly
Corollary: a command defined in file1.ly, shall not be accessible from
file2.ly in the "lilypond file1.ly file2.ly" case. No side effect allowed.
2) A user command defined in one included file shall be accessible from
another included file.
Nobody will make your patches available on retvield for you, and it's not a
matter of fighting, but of reading git-cl README.
Using retvield makes your patches both easier to read and to comment. This
is the current policy on this project, please conform. Yesterday, I
anticipated changes that were yet to come (the unification of both macro),
that's why my comments where out of the point of your patch. I feel that
publishing your previous patch on retvield as expected here, by giving a
clearer picture, would have avoided this situation. Your patch was fine.
Nicolas
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
