Re: Overlay mechanic improvements

[David Kastrup <dak@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Rasmus <rasmus@gmx.us>
>> Date: Tue, 30 Sep 2014 12:35:08 +0200
>> 
>> > 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.
>> 
>> I agree wholeheartedly.  Org has a similar mechanism as well, but it
>> *sucks* compared to preview-latex.  I tried to get
>> preview-latex working with Org (which uses LaTeX-syntax for math), but
>> it was non-trivial.  Thus, I don't interact much with preview-latex
>> these days, but I have very fond memories of using it.
>> 
>> If you ever decide to allocate time to generalize preview-latex and
>> have it shipped with Emacs-core I'd happily support that work!
>
> Feel free to expand on the problem(s) you hint on, because just by
> reading this exchange, I don't really understand what kind of
> facilities are missing in the core.  (I don't use preview-latex and
> probably never will.)

Since preview-latex is trivial to install via ELPA (as it's included in
AUCTeX), I am somewhat at a loss figuring out what point people are
trying to make by stating that they are not going to bother looking at
it, preferring me to type descriptions for hours.

There is a paper
<URL:https://www.tug.org/TUGboat/Articles/tb23-1/kastrup.pdf> sketching
the working mode of preview-latex some more.

But the problem is that static images/screenshots are not really much
help in seeing how the generation of images is actually integrated into
the interactive workflow.  The screenshots would not have looked
significantly different after the first prototype was running, so they
don't really do a lot more than give the information "Emacs can show
images".

I found some conference video Kaveh Bazargan made of me at
<URL:https://www.youtube.com/watch?v=avn7-aVpP9I#t=500>, picture quality
pretty flaky.  While it does not really say a lot about the Emacs parts
of the process, it is pretty obvious that the editing is not at all
disturbed by the images and that any images are regenerated
instantaneously without any obvious delays or interference with the
editing workflow.

That's probably 2007 or 2008, so the processor I use is probably
something like 600MHz.

Emacs does not offer any default support for rendering images on-demand
from source code in a buffer.  The pipelines that preview-latex can be
something like

buffer -> LaTeX -> Dvips -> Ghostscript -> PNG
buffer -> PDFLaTeX -> pdftodsc -> Ghostscript -> PNG
buffer -> LaTeX -> Dvipng -> PNG

It will also run several of those in parallel, like running
LaTeX->Dvipng but falling back to Dvips->Ghostscript for those images
which contain embedded PostScript.  The Ghostscript pipeline will render
the on-screen images first to make for better interactive response.  In
addition to the images, LaTeX produces geometry, baseline, source
location and various other info (for example, default font size in order
to match the rendering scale to the current default screen font) which
is parsed by Emacs and used for integrating the resulting images in the
right place and scale into the originating buffer.

So there are prioritized rendering pipelines and information side paths
that deliver information crucial for tying the image stream back into
the proper buffer locations, with proper scale and baseline.

There is other stuff like being able to paste text plus images into MIME
mails (with the obvious loss of baseline and other formatting
information, but for display math it is somewhat helpful), and desktop
mode saving and restoring the images associated with a buffer.

All of that is not specific to LaTeX, and Emacs does not really provide
anything helpful for creating that kind of facility apart from the
display feature itself and the possibility to run processes and process
filters.

-- 
David Kastrup