Am 21. November 2014 12:36:59 MEZ, schrieb David Kastrup <d...@gnu.org>: >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.
Ok, I see. Thank you for the explanation. I'll try if I can get *somewhere* with an "external" approach as outlined on -user. Urs _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel