RE: metronome-mark-alignment

[Daniel Rosen]

> -----Original Message-----
> From: Thomas Morley [mailto:address@hidden]
> Sent: Sunday, January 12, 2020 6:04 PM
> To: Daniel Rosen <address@hidden>
> Cc: David Nalesnik <address@hidden>; lilypond-user Mailing List
> (address@hidden) <address@hidden>
> 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
> <address@hidden>:
> > 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