> -----Original Message----- > From: Thomas Morley [mailto:[email protected]] > Sent: Sunday, January 12, 2020 6:04 PM > To: Daniel Rosen <[email protected]> > Cc: David Nalesnik <[email protected]>; lilypond-user Mailing List > ([email protected]) <[email protected]> > Subject: Re: metronome-mark-alignment > > Though, I've already heard about difficulties about using scheme to write > own extension pretty often. > Just like you say: > > Am So., 12. Jan. 2020 um 22:19 Uhr schrieb Daniel Rosen > <[email protected]>: > > I want to express how grateful I am to this list for being so helpful > > with this issue, since I have zero knowledge about how to use Scheme. > > (I've tried to tackle the Extending manual on multiple occasions, but > > I find it extremely difficult to understand, probably because I have > > no programming experience.) > > I have the suspicion it's not, because guile is difficult, at least so far as > the > scheme-tutorial reaches out, but because it's difficult to find a way to > modify > LilyPond's default with scheme. In the sense of: > What am I supposed to do with my new basic guile-knowledge? > Note that most used tools in David's and my coding are _not_ native guile- > procedures, but are defined in the LilyPond-source. > Therefore I think the problem is more poor documentation of those lily- > defined tools and/or the lack of commented code-examples using them. > > Could you confirm or is it something else preventing you from starting to > code on your own?
The most important thing preventing me from starting to code on my own is simple: I don't have to. LilyPond natively supports so many different notational constructs that I run into problems relatively infrequently. And in the cases when I do, between the manuals, the LSR, and this list (primarily the archives, and occasionally responses to my own submissions), I've been able to simply copy-paste my way out of practically any jam I've found myself in for as long as I've used LilyPond (which must be almost ten years). As far as the Extending manual goes, though... I could be wrong, but it seems to assume a basic working knowledge of how computer programs and programming languages work that I simply don't have. Going through it, I think to myself that I would need to have one-on-one tutoring sessions with someone in order to really understand it. Take 1.2.1 (http://lilypond.org/doc/v2.19/Documentation/extending/lilypond-scheme-syntax) as an example. This paragraph > The hash mark # method of embedding Scheme is a natural fit for this system. > Once the lexer sees a hash mark, it calls the Scheme reader to read one full > Scheme > expression (this can be an identifier, an expression enclosed in parentheses, > or several > other things). After the Scheme expression is read, it is stored away as the > value for an > SCM_TOKEN in the grammar. Once the parser knows how to make use of this > token, it > calls Guile for evaluating the Scheme expression. Since the parser usually > requires a bit > of lookahead from the lexer to make its parsing decisions, this separation of > reading > and evaluation between lexer and parser is exactly what is needed to keep the > execution of LilyPond and Scheme expressions in sync. For this reason, you > should use > the hash mark # for calling Scheme whenever this is feasible. mostly goes over my head. I like to think I understand the basic idea, but I can never be sure because I'm unfamiliar with so much of the language: "lexer," "Scheme reader," "SCM_TOKEN," "parser." And the rest of the page is no better. So while I'm sure that you're right about the manual's ineffectiveness in helping readers transfer their knowledge of Guile into practice within LilyPond, in my case the issue lies even deeper than that---I'm never sure whether I'm really understanding what the manual is trying to tell me. Of course, it may be that the manual isn't meant to be aimed at a complete novice like myself; but if it is, then it definitely needs an overhaul. DR
