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" <gra...@percival-music.ca> 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 > _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
