Re: survey on multiple development versions

[David Kastrup]

Carl Peterson <address@hidden> writes:

> On Tue, Dec 10, 2013 at 10:23 AM, David Kastrup <address@hidden> wrote:
>
>> If we have branches with personal interests, it must become more
>> feasible for the respective authors with personal interests to
>> provide binaries if they consider that a good idea.  Any solution
>> that will only work via the "Phil, do more" route is not going to
>> scale.
>
> This, to me, sounds like a "plug-in" solution is needed, at least for
> things that do not involve changing the C++ code (and maybe even
> then).

That's very much my opinion.  Recompilation is a very high threshold,
and crossing it basically is platform-dependent.

That means that we should strive to factor out as much as possible into
Scheme.  That is not, by itself, going to help.  It is also necessary to
factor the stuff into sensible units.

If we take an example of one item that has been mentioned: footnotes.
Footnotes consist of material that is anchored to locations on the page,
and that is assembled into a footnote block of its own taking space on
the page.

Basically all of that is done interweaved into other C++ code.  Which
does not make a whole lot of sense since it is a reasonably independent
task.

If we are taking a look at why this happens, we can basically state as a
goal to factor out the "page builder".  The page builder is part of the
page breaking calculation, and as such

a) its material have to be placed in special lists which are processed
for page breaking
b) its material contains items like "springs" that are not actually
creatable or accessible in Scheme.

So if we are going to use markup lists for building up a page from its
elements, we need to have proper Scheme and likely also LilyPond
representations of the items making up the material assembled into a
page.

Refactoring the page building into a stage where its basic operations
can be done from Scheme/LilyPond would be a first big step towards being
able to experiment with different schemes without recompilation.

The next big step would be to create a modular structure where it is not
necessary to replace the page builder for a feature like footnotes, but
where you can plug in elements like footnotes by writing code for them
and plugging this code into a single, extensible page builder with
appropriate interfaces.

Then we can have, without recompilation, tools that provide smarter
footnotes, different layouts of them, margin notes and other stuff
without interfering with other tools available for the page composition.

The LaTeX core project is rather religiously keeping from ever touching
the canonical TeX binary, and this has had quite a few ridiculous
consequences.  But it also enabled a large body of grown LaTeX/TeX code
that can be used in parallel, due to some abstractions and interfaces
and conventions that are far from convincing or enforceable in their
technical implementation but which definitely do much more for being
able to let multiple independent solutions be combined than the basic
"plain TeX" format does.

> The question is, if we're looking at releasing these binaries to
> reflect personal interest, how much are they actually going to be
> used? I have the feeling, though it may be unjustified, that while
> there may be a few people who would grab a binary with an experimental
> feature (self included, if it is one that I'm interested in and know
> something about), the use of the binaries may not be enough to justify
> the extra effort to make them available.

I share that concern.  For that reason, I'd consider it important to
spend a significant amount of effort not on thinking about "how can
expert programmers make LilyPond do something new" rather than "how can
experienced users make LilyPond do something new".  Or even something
old.  One part of the "programmer"/"user" distinction is that adding new
functionality should _not_ require tampering with the existing
installation, making it compile existing files differently when they
don't access the added functionality.

-- 
David Kastrup