Re: Future of OpenLilyLib

[Mark Knoop]

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