Re: Partial compilation (again)

[Urs Liska]

Am 21. November 2014 12:36:59 MEZ, schrieb David Kastrup <address@hidden>:
>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.

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