On May 5, 2004, at 8:31 AM, Heikki Johannes Junes wrote:
Formal language reference sounds just good. It would show explicitly
that
LilyPond has a coherent syntax. The value of the language reference
would
increase a lot, if there would also be given the version indication:
(since 1.7.23)
That
On Tue, 04 May 2004 13:15:12 -0400 David Brandon <[EMAIL PROTECTED]> wrote:
> On May 4, 2004, at 4:20 AM, Stefaan Himpe wrote:
>
> >
> > Sounds like an interesting plan, but have a look at the existing
> > documentation first, I think there is already quite some reference
> > documentation avai
On May 4, 2004, at 2:00 PM, Han-Wen Nienhuys wrote:
This is a good initiative. If you really want formal, you could
consider writing the documentation as doc strings, at least for the
music expressions. See scm/define-music-types.scm for examples.
Aha, excellent! I will see what I can come up wi
[EMAIL PROTECTED] writes:
> On May 4, 2004, at 4:20 AM, Stefaan Himpe wrote:
>
> >
> > Sounds like an interesting plan, but have a look at the existing
> > documentation first, I think there is already quite some reference
> > documentation available. (from the website: follow the links to
> >
On May 4, 2004, at 4:20 AM, Stefaan Himpe wrote:
Sounds like an interesting plan, but have a look at the existing
documentation first, I think there is already quite some reference
documentation available. (from the website: follow the links to
documentation, then program reference)
Well, yes,
> I think that is a good idea, because there would then be a proof of
> concept to show to developers. I think what has happened is that the
> developers have concentrated on features and output. That is great,
> because the output is pretty impressive. They did not think about
> language desig
foo = \notes { c'8( d') e'( f') g'4( a') }
\score {
\notes {
\foo
{
Stem.thickness = 4
Slur.transparent = true
\foo
}
\foo
}
}
David,
I too believe that syntax can be made much more
simple and have more uniform look and feel
wit
Well, first I'd say to not take anything I say too seriously. I am new
to this project and I definitely don't know everything there is to know
about the code by any means. In fact, I don't know much, yet.
What I'm thinking about, I guess, is that for developers the mixing of
scheme and lily i
Fri, 30 Apr 2004 14:39:46 -0400, David a dit :
> I'm a little bit worried about the architectural implications of this
> entire line of discussion. I mean, lilypond syntax is already a bit
> of a frankenstein monster of mixed TeX and scheme. I think
> encouraging too much embedded scheme is
Fri, 30 Apr 2004 20:21:48 +0200, Nicolas a dit :
> However, this requires a music printing function, which is not
> exactly trivial.
Never mind. There is a trivial solution, ie generating an expression
like
#(ly:export (make-music 'XXXEvent 'property value ...))
__
I'm a little bit worried about the architectural implications of this
entire line of discussion. I mean, lilypond syntax is already a bit of
a frankenstein monster of mixed TeX and scheme. I think encouraging
too much embedded scheme is an approach which has the potential to make
lilypond sou
hi
A question about the use of variables in an embedded lily forms.
As it is done now,
#{ \override TextScript #'padding = #$pad #}
is read as:
#(ly:parse-string-result
(format #f " \override TextScript #'padding = #~a " pad)
(current-module))
that is, `pad' is written in the str
12 matches
Mail list logo
