Re: survey on multiple development versions

[Mike Solomon]

On Dec 10, 2013, at 6:32 PM, David Kastrup <address@hidden> wrote:

> 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.

I agree that this is a great candidate for refactoring.  I think one way to 
frame the problem would be to imagine that someone wanted to take on this task, 
which is pretty ambitious and would likely require a lot of subtasks in 
extracting out the page breaker.  Each of these subtests would require 
independent verification, and it is likely that the entire project could be 
done separately from the main branch.  It would probably require extensive user 
testing to make sure that all the kinks were ironed out.

Let’s say that I set up a version of LilyPond called modular-footnote-LilyPond 
in which I develop this modularity.  How, if at all, can users test this before 
it makes it into the development version?

Cheers,
MS