Re: Constructive Criticism and a Question

[Mats Bengtsson]

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