Jonathan Henkelman wrote:
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).
Of course!
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?
Since the parser is implemented using lex and bison, there shouldn't be any
formal inconsistencies. At second thought, larger and larger parts of
the syntax
is now implemented as Scheme functions, but they too have a formal
syntax check.
However, I'm sure you can find lots of language constructs that are
confusing.
Note that the syntax and semantics has evolved over the years and still is.
Many of these changes have in my opinion made the syntax more consequent
and simpler.
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
This is one concern I have raised a couple of times. There are lots of
optional
constructs, which often confuses new users. They certainly save some typing
and perhaps lower the initial threshold a bit for new users. However, I
think the
reduced number of key strokes only is significant in small test examples
(which
is what the main developers mostly do, and myself and other who help on the
mailing list) but not in any real world typesetting.
- 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)
That's what convert-ly does.
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
See "Creating contexts". Use \new if you want to make sure to get a new
unique
context. Use \context if you want to add on to an already existing one.
However,
you can use \context to create a new context if you manually make sure
that the
identifier is unique, so there's a flexibility that may cause confusion.
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.
If you search the mailing list archives, you will find lots of
discussions on the
\partcombine function. The general conclusion is that it often doesn't
do what
you want to do and that it's impossible to support since the
implementation is
too complex. However, there are plans to reimplement it from scratch.
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...)
See www.lilypond.org -> Documentation or www.lilypond.org -> About for
links to the mailing list archives and administration pages where you can
subscribe to the mailing lists and after that use your ordinary email
client to
send emails to the lists.
/Mats
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user