Urs Liska <u...@openlilylib.org> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel