Re: Modularity in lilypond

[Mike Solomon]

True that.

My three.5 concerns are:
1) said code cannot use non-public scheme functions (am I right in thinking
that?).
2) changes to init.ly are not copied from one version of lilypond to the
next, nor are one person's "modules".  I do my compiling from the git
repository, so I could likely rig something like that for my own machine,
but I imagine this is even more problematic for someone downloading a
GUB-made lilypond.  I had this problem with my site-packages when I updated
from Python 2.4 to 2.6, and it took me days to get back things as I had
them.
3) There should be some sorta standard practice (ie template) for how
modules are written (I believe that's what David was referring to).
3.5) I stand by my assertion that certain features of lilypond should be
turned into modules if lilypond is to grow to be as encompassing as
something like j-edit or emacs.  Given the many amount of musics in this
world, if lilypond wants to grow to be as wide-reaching as possible, such a
move seems logical for subsequent versions.

Any ideas would be appreciated!
~Mike

On 7/29/10 7:47 PM, "Graham Percival" <address@hidden> wrote:

> On Wed, Jul 28, 2010 at 04:25:08PM +0200, Mike Solomon wrote:
>> 1)  A folder would be created in (ie PATH/lilypond/2.X.X/module) in which
>> all modules hung out so that Lilypond knew to look there.  Each module would
>> have its own folder and could be internally organized however one fancies.
> 
> Kind-of like the /ly/ dir?
> 
>> 2)  A document would be created that invoked all modules that were
>> perma-invoked.  That is, any module should be able to be called in a given
>> document, but if the user wants certain modules to be called all the time,
>> this document should do it.  Ideally, the document would be nothing more
>> than a series of \include statements.  It would have to have a standard path
>> that would not get overwritten from version to version (which would likely
>> involve some copying and pasting combined with some simlinkery).
> 
> Like /ly/init.ly ?
> 
>> 3)  Certain current features of lilypond would need to be modularized.  This
>> is probably the most difficult call, as it brings up the question "what
>> should be part of non-modular lilypond"?  There are certain things, such as
>> notes, dynamics, and slurs that seem like they should be in any typesetter,
>> whereas woodwind fingering charts, fretboard diagrams, and harp pedals seem
>> more modularish.
> 
> Like \include "gregorian.ly" ?
> 
>> P.P.S. It could be that such a modular system already exists and I am simply
>> not privy to it, in which case I'd appreciate any feedback!
> 
> I'm not certain if you're aware of the ly/ dir, but if not, you
> should definitely look at those.
> 
> Cheers,
> - Graham
>