Re: "Collect" barnumbers for line and page breaks

[Urs Liska]

Am 10.01.2015 um 22:04 schrieb David Nalesnik:
> On Sat, Jan 10, 2015 at 2:06 PM, Urs Liska <address@hidden
> <mailto:address@hidden>> wrote:
>
>     Hi David,
>
>     thank you for that suggestion.
>     I'll try to get my mind around this ASAP.
>     On the first sight I don't understand too much of it. But at least I
>     notice that I'm not afraid of these lambda, let and let* constructs
>     anymore. Finally I'm getting *somewhere* to familiarity with the
>     basic working of Scheme code. What I'm still at a major loss is how
>     Scheme interacts with LilyPond specific functionality. There's
>     really a need for education in that sector.
>
>
> Yes,  The Scheme comes in a natural progression..  There's plenty on the
> internet to assist self-study, and you can do a lot with simple
> constructs.

One thing I found particularly preventing progress is the variety of 
Scheme dialects, and the fact that the learner isn't pointed to that 
fact enough. If you're looking for solutions on the internet they so 
often just don't apply to LilyPond, and if you're looking for 
documentation it's just the same. If you're looking for topics like 
recursion, list access, loops or whatever, chances are quite low that 
search results will lead you to pages that actually help you, instead 
they are extremely confusing to the learner, simply because solutions 
may not work in LilyPond.

By now I know that I should never enter "scheme conditional" in a search 
engine but rather hope that "guile scheme conditional" will give me a 
helping hand. But it's just recently that I found this out. OK, it *is* 
stated on 
http://lilypond.org/doc/v2.18/Documentation/extending/scheme-tutorial.html, 
but this is in a way that you never understand the implications until 
you return to it when you already know about it (just like me rereading 
this now).

> LilyPond internals?  There's huge room for
> documentation/tutorials here.  Not just explanations for the user, but
> comments in the code, of which there are precious few.

The internal reference of Scheme functions is quite a nightmare for 
people like me. I think it can be used as a "desktop reference" for 
people who are really familiar with what

ly:add-option sym val description

might mean, but for me it's mostly only helpful for getting a vague idea 
where I could start trying.

> I would love to help out with this, but I don't know where to begin!

Well, the most important thing is not to think you'd have to do 
everything in one go, not even having to ensure that a first step leads 
to a consistent whole in the future.
I think if we add items to the collection of slow-paced tutorials each 
single item is helpful. I think what I've tried with my first Scheme 
tutorials is about the right direction. They deal with a very small 
topic but try to be quite elaborate and give the reader a chance to 
slowly consider the topic from all sides.
Everything that goes into LilyPond's official documentation is more or 
less forced to be *concise* - which is of course necessary from the 
perspective of the project but not too helpful to get people into this 
complicated matter.
So if you would for example write one tutorial at first (even when it 
should be split into a number of posts) explaining one aspect thoroughly 
this would be very helpful. Think about phrases that are commonly simply 
used to give some other expert a hint but don't say anything to others. 
Just a few ideas for such tutorials:

- What does "overriding a stencil" mean and imply?
- What is an engraver, really?
  How to write one, why? What do the discussions mean about
  which information is available at which stage?
- Where do these ly: functions come from?
  -> how can we interact with LilyPond internals?
- How do define-music-function and friends relate to plain "define"?
- etc.

If you'd be ready spending some time writing (a) tutorial(s) we could 
surely find something useful and practical for you ;-)

Best
Urs

> David


--
Urs Liska
www.openlilylib.org