Hi all, Am 31.12.2016 um 10:31 schrieb David Kastrup: > I would urge the openlilylib > crew to assess their current work and see whether they consider any > parts suitably stable and robust and useful to include in the next > release.
I see three items in openLilyLib that I would like to discuss in this context, before possibly investing any work, one small and two bigger ones. 1) I am very happy about the LilyPond version predicates that allow you to write code that supports multiple LilyPond versions. This is a complementary use case to convert-ly for cases (libraries or frameworks) that are intended to support e.g. stable and devel versions. Through calls to (if (lilypond-greater-than? '(2 19 21)) (and the sibling procedures) alternative code can be evaluated depending on the currently run LilyPond version. openLilyLib makes quite some use of this, particularly around the "parser" thing. I'd like to create a patch for this if there's no objection already at this stage. 2) "Option handling" A fundamental feature of openLilyLib is what I called "option handling" but which is actually somewhat more, kind of data handling (don't know what a proper name should be). It is a Scheme tree object that can hold arbitrary data (originally: options) that can be accessed through - \registerOption - \setOption - \getOption[WithFallback] - \[get|set]ChildOption There are two main points to using/having it: a) there's only one distinct name around, so you don't have to "pollute" the namespace with variables. b) it is very easy to use and it has proven invaluable to me for creating infrastructures - as it gives a quite high level access to something that would otherwise be quite painful and therefore comparably unused. The original idea was to establish options with default values (a library would e.g. initialize with \registerOption scholarly.annotate.use-color ##t ), while the user could configure the actual behaviour with \setOption scholarly.annotate.use-color ##f Library functions would then implement switches according to option values. In the meantime I have realized that the "options" can be used to store arbitrary data, for example parsed music expressions. In a project I parse the parts and store them in "options", and when I then create individual parts and the score they can be reused without having to be re-parsed. So I think this functionality would be a very useful enhancement to the programming toolkit for LilyPond. Regarding the implementation in LilyPond itself I can't say how much work it will be to pull it out of openLilyLib and re-implement in vanilla Lilypond. Probably this would be an independent Scheme module (where one had to discuss if it's loaded automatically or only provided to be used). Additionally this would add quite a number of useful lower-level functions (by Jan-Peter) that simplify the use of association lists in general. 3) As it has just been discussed I'd like to ask if we should make an effort incorporating the \shapeII improvements into \shape. One problem I see here is that this probably wouldn't simply be about including existing code in LilyPond. I have the impression we would have to look at \shapeII (as per openLilyLib) and reimplement it on top of \shape, partially because there is now much better support for the complex geometric calculations Janek did "by hand" then. I have the impression this might be too long a shot to get into a stable release by February. Bot OTOH it would be so much worth the effort to have in a 2.20, considering that a 2.22 is presumably quite some time away. What do you think? Best Urs -- Urs Liska https://openlilylib.org http://lilypondblog.org _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
