Graham Percival <gra...@percival-music.ca> writes: > On Fri, Jul 02, 2010 at 04:54:11PM +0200, David Kastrup wrote: >> There is no documentation as far as I can see, > > Our stated (albeit probably only on the mailing list) policy is > that new features don't need docs from the programmers; as long as > there's sufficient regtest(s) and the programmer talks to the doc > people, we can the docs up to other people.
That policy would be less of a tradeoff if we had better modularity. If an undocumented feature does not get in the way of my understanding better documented code and features, it is strictly better than the feature not being there at all. But when we get to a state where most features will not be used by most people, we don't want to have them get in the way when unused. LaTeX and Emacs are such grown systems where 95% of all users will each consistently use less than 5% of the available code. And almost all code sits completely in separate files, in separate directories, with separate documentation. You can ignore any package you don't understand for lack of documentation, and never run into its code while debugging. >> It seems nice to be able to add this sort of thing to Lilypond, but I >> think it rather strongly demonstrates Lilypond's lack of modularity: >> this sort of thing should sit in a separate directory and be loaded >> on-demand under user control without needing any resident code parts >> when people don't use it. > > If it was all done in scheme, this would be easy. :) I don't think so, since properties and contexts are defined and initialized globally right now, and we don't have a system for modularizing documentation. Or am I missing something completely obvious? -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
