David Kastrup <[EMAIL PROTECTED]> writes: > > > > Thereafter, the black box that is LyX's "run queue" sounds very > > similar indeed to preview-latex. Does it not run as a forked process > > and tell emacs when to load an image? > > Uh, not really.
[Details snipped] I explained in detail what we do but got sidetracked and forgot to pinpoint the difference. Emacs is in control here completely and initiates the conversion, some of which is done in batch stages working on all images of one preview run, and the last of which (GhostScript) works on per-image basis. GhostScript just tells Emacs when it has finished another image. We basically have a queue of images that need to be rendered, and this gets filled in the first place as follows: Emacs under user control runs a region or file with preview.sty active through LaTeX. The output of this run determines where and what images gets placed: it fills the run queue and replaces all of the source sections by "work under construction" signs and enters each of them into the basic work queue. Then the whole queue gets worked off. Emacs' redisplay code calls a redisplay hook whenever it displays one of the "work under construction" signs on the screen, and this moves the image in question to the front of the work queue, so that it gets rendered with priority. Emacs basically converts all images and places them in the buffer. A display image property specification for Emacs can point to a graphics file (in our case, preferredly png). When this image appears on-screen, Emacs still needs to load it, but this is fast as compared to the other conversion stuff. So with Emacs, we have no "forked process" telling it when to load an image. The converters basically convert _everything_ Emacs cannot load natively until they are in a "fast" format. They can be made to start their work on the "important" images (on-screen), and this may change dynamically as the user pages through the file with unfinished images. But in the end, we convert everything, and the order might be determined by Emacs' redisplay, but not a forked process. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
