Thanks Jean for your thoughts, which are not so far from my own. A few comments:
> Maybe what I'm going to say will sadden some, but personally, > I never quite understood what the advantage of developing > openLilyLib as a library external to LilyPond, as opposed to > contributing features to LilyPond itself, was supposed to be. Having just looked through quite a lot of the code in openLilyLib, I think there will always be code there that is not suitable for inclusion in LilyPond, for many reasons (highly specialized use cases, code which works just-well-enough™, etc...). It's no criticism of the core LilyPond developers to acknowledge that not every desired feature will be accepted, and even if so, there is still a significantly higher hurdle to contributing to LilyPond than to OpenLilyLib (and rightly so). Almost all programming languages have non-core features which are developed in a modular way - this fact would seem to support the case for something similar for LilyPond. > I was going to add my lyrics code to LSR, actually. It's just > more convenient for users to grab, and it's not like this is > a very large piece of code that really needs version control > (although version control in LSR *would* be nice). I see two advantages over LSR, the primary one being version control (which includes being able to search it locally with git grep); the other being the potential to include code which is larger in scale and interacts sensibly. (Once you start importing several LSR snippets into one project, the potential for adverse side-effects becomes > 0.) > To be honest, although I wasn't there at the time, it is my > impression that this split was partly motivated by some personal > conflicts that reduced Urs' willingness to submit patches to > LilyPond, which is not relevant for us today. Indeed, this isn't relevant, except to acknowledge that for whatever reason, there is at the moment a bunch of useful stuff which is a) not yet in LilyPond, and b) bit-rotting until it is dealt with. > Some of the OLL stuff has been made part of LilyPond over the > years, for example Merge_mmrest_numbers_engraver and \vshape. > There is also \staffHighlight, which serves a purpose that > overlaps a bit with the purpose of AnaLYsis. Long-term, I would > like to see edition-engraver go that route as well (with a > better, iterator-based implementation). Absolutely I'd also love to see this. (Another task which I didn't put in my first email is to clean out code that *has* made it into LilyPond.) Whilst I was able to fix-up the edition-engraver for Guile 2, I am certainly not up to rewriting it "better" - and I don't expect anybody else to do that either. My hope is that by making OLL a little more usable and less chaotic, it might be possible to identify firstly which features are being most used, and secondly use that information to prioritize moving those into LilyPond in the best way possible. -- Mark Knoop
