Re: Partial compilation (again)

[David Kastrup]

Urs Liska <address@hidden> writes:

> I have another suggestion, somewhat related to
> http://lists.gnu.org/archive/html/lilypond-devel/2014-11/msg00139.html
>
> I would still like to see the possibility to re-compile individual
> staves only.
> And with a sloppy-line-breaking option (maybe in combination with
> system-wise output à la lilypond-book-preamble) risk is much lower
> that changes in line breaking interfere with that. (Of course that
> scenario has to be taken into account).

[...]

> I know this may be a rather big task, but I think that adding a
> partial compilation feature would be a very good thing in order to
> keep (or even make) LilyPond more competitive.

For one thing, it's a lot of a hen-and-egg problem.  This would require
heavy support from the application driving LilyPond.  I see this as
somewhat more feasible from systems like Denemo rather than Frescobaldi
since Denemo understands the LilyPond code it produces and would be able
to figure out the details involved with retypesetting parts.

For stuff like Frescobaldi, I don't really see reliable strategies.  For
MusicXML rather than the LilyPond input language, stuff might be more
straightforward.  Of course, parsing is a pretty fast part of LilyPond
so one could likely afford not doing partial reparsing but reparse the
whole document and consequently work on a less stateful representation
of the score.  Doing partial iteration would be trickier since the state
is not just stored in context properties but also in engravers' own
local variables.

In either case, the problem space is similar to that of the much wider
used LaTeX, and for LaTeX there are no really convincing retypesetting
scenarios (well, preview-latex works in a problem subspace that's handy
for editing but not-the-real problem, and I don't see that easily
extending to LilyPond which works with a much larger amount of relevant
hidden state being dragged around during compilation).

So I don't see this going anywhere fast.  To get a hook into cloning
internal engraver states, you'd probably want to create a more
object-oriented frame work for them.

-- 
David Kastrup