Re: Overlay mechanic improvements

[David Kastrup]

"Stephen J. Turnbull" <address@hidden> writes:

> Richard Stallman writes:
>
>  >     > Does this mean you turn off display of the image on the
>  >     > overlay when the text in that region is changed?
>  > 
>  >     Very much so, yes.  Changing the text in the region would be a
>  >     pain if you could not see it, and changing it breaks the
>  >     correspondence between text and image anyway.
>  > 
>  > I see.
>  > 
>  > But you keep the overlay in existence -- how come?
>
> Why do you care?  David knows his business, isn't that good enough?
> (These are real questions, not an attack.  It would be easier to
> answer your questions informatively if we knew where you are going.)

Well, there are, of course, places where one might want to go.
Historically, preview-latex was inspired by Emacs 21'st upcoming ability
to integrate EPS images into a buffer, with a proof-of-concept up in
about a week.  Getting the whole thing to work as one smooth application
took quite more than a man-year and a number of collaborateurs, however.
And part of the reason for that is that is that a lot of functionality
had to be implemented from scratch to be usable: static screenshots
don't really reflect the interactive nature and efficiency with which
one could work on complex documents with 1000+ equations while having a
single 200MHz processor at one's disposal.

One key element is using DSC comments in the generated single PostScript
file for out-of-order rendering of images: Emacs entertains a pipeline
into a Ghostscript process that first gets all on-screen images
converted into PNG graphics before it reverts to conversion of the
remaining off-screen material.  If the on-screen regions change, the
rendering pipeline switches the workload accordingly.  With today's
processors, it is actually hard to see that effect in action, but at the
time it was implemented, scrolling around in a partially rendered buffer
lead to an xroach-like effect where changes in the window lead to
new images scurrying in until the display was static again.

This sort of display-oriented rendering pipeline is not in any way
specific to working with TeX/LaTeX.  It is infrastructure that would be
nice for a whole lot of things.

In its current form, the code works in AUCTeX's LaTeX mode.  It does not
work for Emacs' builtin TeX modes, not even its LaTeX mode (mostly
because of being tied in the process management and keymaps of AUCTeX).
It does not work for AUCTeX's TeX or Texinfo modes (and the latter would
be nice for working on GNU LilyPond which uses lots of images in its
manuals generated from source code in the manuals).  It does not work
for calc's TeX output (which would increase its readability and
usability significantly).

It does not work for other image-generating modes like LilyPond-mode.
I think that something like some Maxima-mode or similar copied an early
version of preview-latex in order to implement some similar
functionality.  It's probably fallen victim to bitrot long ago.

preview-latex does an excellent job, but much of its code is not at all
related to the AUCTeX user interface or the LaTeX input language, and
yet it will work for nothing but the AUCTeX user interface and the LaTeX
input language.

And without generally available facilities to do that sort of work, it
will remain a singularly useful application without peers.  Because it's
far too much work to do a peer from scratch for similar needs.  It was
supposed to make it easier for me to work on my PhD thesis, but I ended
up doing it _instead_ of my PhD thesis.

The main shortcoming of preview-latex in my book is that it stands out.
It should be one of possibly many thin applications on top of rendering
frameworks provided by Emacs proper.

Like I said: the barely-workable proof-of-concept (good for screenshots
but not actual work) took about a week.  The ideal state of Emacs would
be that implementing similar functionality for a comparable text input
language that can be rendered into PostScript graphics with DSC comments
(a non-trivial subset) or into PNG images or whatever, would take about
that long.

That would get us to see a whole lot more editing modes with
supplementary graphic support.

That this shortcoming of Emacs can be cured on the Elisp side alone (as
preview-latex does not need more than a working Emacs 21 binary) does
not make it less of a shortcoming.

-- 
David Kastrup