lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Constructive Criticism and a Question


From: Jonathan Henkelman
Subject: Re: Constructive Criticism and a Question
Date: Mon, 18 Dec 2006 15:11:14 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

Graham Percival <gpermus <at> gmail.com> writes:

> 
> Jonathan Henkelman wrote:
> > In terms of making it easier, I don't know if it would be straight forward 
or 
> > not, but if the PDF version of the manual had chapter numbers in the table 
on 
> > contents that showed on the bookmark pane (to the left) it would make it 
much 
> > easier to bounce around and find one's way back again.
> 
> I'm sure that this can be done by adding a few words to some part of the 
> doc and/or makefiles; the problem is simply finding the right place and 
> figuring out the words.  I'll look into this.
 
Thanks much.

> > Is there a copy of the so called "programmers documentation" in a suitable 
> > format to download i.e. PDF (I know it would be long) or a few large HTML 
> > files, or an archive (tarball - whatever) of the current HTML 
documentation.  
> > I was hoping to do a bit more work on this over the break, but will have 
very 
> > limited web access... 
> 
> There _is_ a documentation tarball, but I'm not certain if it includes 
> the program reference.

I have downloaded the tarball and it had the internals, but the links are 
broken apparently because the file extensions are not explicitly in the 
links.  I am running IE 6.0.xxxx on Win XP.  Perhaps it is a configuration 
problem in IE on my part.
 
> > Some type of doc. that oulined the 
> > lexical construction of Lilypond would be helpful.  I am not used to the 
level 
> > on confusion I am experiencing now, when learning a "language".
> 
> As with all open-source projects, documentation depends on interested 
> people writing material.  I don't have the time to pursue such a 
> project, but if you (or somebody else) wrote this material, I'd be more 
> than happy to add it to the manual.
 
Ay - I hear you there.  I have been considering taking on this project, and I 
still need to figure out if I have time before I get myself in over my head 
and unable to keep up with the commitment others might have made to me.  A 
couple of questions I have been pondering in this regard:

1) Since I am fairly new to Lilypond, are there folks out there that would be 
willing to aid me in the likely event of confusion (I assume this group will 
do).

2) If/when inconsistencies in the language turn up - as I'm sure they will - 
is there an interest amoung the programmers to correct these?

3) A complaint I have seen both commonly on this archive and also on 
the "todo" list of the co-ordinators for lilypond, is to try and make the 
learning curve a bit less steep.  One logical outcome of a document of this 
type is that it can be used to "clean up" the language - i.e. fulfilling this 
last goal.  Is there any interest on the part of the programmers/organizers to 
undertake this task should I ever get this doc completed.  I envision a 
process whereby the basic notation of lilypond stays the same (obviously), but:

- perhaps some command forms would be dropped, 
- perhaps users would be forced into less freedom in the syntax
- perhaps come commands would be morphed to fit into a framework that more 
closely matches other commands.
- any changes would idealy be changeable in input scripts using some sed/diff 
routines to update routines would be automated (no point in unnecessarily 
agravating the end user)

Some examples:
As I can see it now, there are numerous ways to create contexts.  In fact if I 
understand correctly, most commands create contexts.  One example I saw in the 
archive explicly used the context command in all (most?) of these cases.  
Perhaps either forcing the use of context everywhere a context is being 
created, or eliminating its use altogether as it is basically implied 
everywhere would be helpful

I have been banging my head against the \combineparts routine.  Mats suggested 
a different form using polyphonic notation which does the task just as 
nicely.  \combineParts does not (to my naive eyes seem to fit the same form as 
the other commands (e.g. \new Staff, \new Voice etc.) Differences such as this 
make the learning curve steeper.

I think in the end Lilypond would be a cleaner language, but as always happens 
when trying to eliminate legacy code there is always someones toes being 
stepped on...

What do people think about this...

[snip established and reported error]

> > Finally, is the web interface for posting to this archive the most 
straight 
> > forward method?  I tried posting this yesterday, but it got lost in the 
> > ether.  Is there perhaps an email address I can send the post to, where it 
> > will get sent back for validation etc.
> 
> I believe the email address is at the bottom of every message on the 
> list: lilypond-user <at> gnu.org

Not on my web based threaded client (Loom?).  I feel like such a newbie, but I 
can't find it on the FAQ or anywhere else...  I can post to gmane.test, but 
how would I post to followup without using the web interface (i.e. to avoid 
the top-post checking in cases when I am not actually top-posting...)

Thanks,
Jonathan





reply via email to

[Prev in Thread] Current Thread [Next in Thread]