Angus Leeming <[EMAIL PROTECTED]> writes:
> What we need to do is to gather together a number of snippets into Andre's
> "run queue" and then fork this off as a separate process. Let's treat this as
> a black box for now
> input: X latex snippets
> output: X bitmap image files that will be produced at different times.
>
> The devlopment work that we need to do within LyX then is to modify
> our "forked call controller" class so that it can deal with events
> from a running process, not just tell us "the process has finished,
> now deal with it".
>
> 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. The current implementation runs LaTeX with
preview.sty on the region or document to be examined. The "auctex"
option to "preview" spews out error messages for the beginning and the
end of every element it finds displayworthy. Those error messages
allow Emacs to pinpoint the cursor locations where previews
originated in order to replace their source text with a preview. The
usual manner of working is:
1. run LaTeX in background.
2a) run an Emacs procedure that analyzes the error messages from the
LaTeX run, determines all locations of previews in the source
text and prepares the Emacs data structures for inserting them
2b) run Dvips on the DVI file in background
When both 2a and 2b have finished, we continue with
3) Parse the PostScript file for DSC comments in order to find
PostScript Prolog and page locations in the source file.
4) run GhostScript in a pipe. Whenever GhostScript issues a prompt,
we feed it new parameters for the next "page" (dimensions, colors
and stuff) and insert a possibly finished "page" into the Emacs
buffer. Errors lead to GhostScript being killed and a new one
started with the old prolog, while the error generating particular
preview gets replaced by clickable links to error message and
location in PostScript file. If GhostScript bombs out before
starting on a snippet, the run is aborted completely, with the
error message being inserted into the general log file buffer.
This interplay is currently rather hardwired. I am currently working
on rewiring the logic. Emacs does not really fork itself except for
executing programs. It is not multithreaded. It has a sort of
synchronous multitasking, however, that can call sentinels (when a
separately started executable finishes or gets killed) and filter
routines (when a separately started executable has produces output).
This makes it possible to let separate programs be run more or less
in background as long as they are separate executables.
Longterm plans are to make the various stages in such a conversion be
submodules, that way making it easier to replace DVI by PDF, or Dvips
and GhostScript with dvipng, and even LaTeX+preview.sty by different
DVI producers (prepping up TeXinfo and Emacs calc with TeX images
would become more feasible).
> Are we gettting warmer/closer together?
Well, we probably have similar rendering pipeline functionality to
implement, but we will have a completely different code base for the
pipeline stuff itself. It will take some time until I have that
cooked out well enough and versatile and flexible enough for most
purposes under preview-latex. When it is finished, it might or might
not be interesting for you to take a look at what will then constitute
a method in our pipeline stages, and of course, the actual strings
that get sent to and interpreted from external programs might also be
worth taking (I have already picked out quite a bit from the stuff
that we use and tried to make it apply for your purposes, hopefully
without getting too much of it wrong). In short, I guess you are on
the right track to get things right more or less at first try. I'd
sure like to be as effective as you are.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: [EMAIL PROTECTED]
