Carl Peterson <[email protected]> writes: > On Tue, Dec 10, 2013 at 10:23 AM, David Kastrup <[email protected]> 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 _______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
