Le 21/11/2022 à 20:02, Mark Knoop a écrit :
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).
That is true. On the other hand, the hurdle for contributing to LilyPond is already significantly lower than it used to be a few years ago (we migrated to GitLab, large parts of the contributor's guide were rewritten, ...). It's all a tradeoff. The less requirements you put on quality, the more maintenance trouble you get (and there is an inherent maintenance trouble related to the fact that OLL is not usually constrained to a single version of LilyPond, although you are proposing to make it so in the short period until 2.24).
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.
A Python library for scientific computing has absolutely nothing to do with a Python library for creating web pages, so the developers have no reason to tie themselves together. In contrast, music typesetting is an intricate task with dependencies everywhere.
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.)
I dream of a remake of LSR that would fix its problems (lack of history / version control, LSR editors don't know who submitted a snippet and are not notified about it, things like that). On the other hand, when I see a large snippet of useful code, my first reaction is normally to wonder how some of it could be turned into a patch.
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.
Yes.
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.
Iterators are currently not Scheme-accessible anyway. It would have to be done on the C++ level.
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.
Good. Best, Jean
OpenPGP_signature
Description: OpenPGP digital signature
