OLL features (was: LilyPond 2.20 release process)

[Urs Liska]

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