Re: Overlay mechanic improvements

[David Kastrup]

Richard Stallman <address@hidden> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> Thanks for the explanation.  Now I understand, more or less.
>
>     If you write, say, word_text instead of word\_text (throwing LaTeX into
>     inadvertant math mode), the resulting nuisance overlay will need to get
>     manually removed (with keyboard sequence or mouse click) after
>     correcting the syntax error since no image will reappear in that area
>     after the correction.
>
> If you regenerate that region, and it makes no image, can't that delete
> the overlay automatically?

Conceivably.  However, a region might just be

    \input{bozo}
    \input{clown}
    \input{summary}

with the actual images appearing in respectively other buffers than the
region.  So clearing out the original region would be a heuristic rather
than the full deal and should not be mandatory for satisfactory
operation.

>     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.
>
> What is the obstacle to supporting other interfaces?

The job control that is used is that of AUCTeX.  That involves
management of various process buffers (without getting "A compilation is
already in progress" problems), expansion of commands with variable
elements based on the involved buffers and files.

The command sequences which are executed are based on the various ways
of generating graphical output from TeX input.  These kind of chains are
not really specified as some sort of abstract interface but hardcoded.

There are sidepaths from LaTeX for geometry and source location
information: Emacs parses the resulting error/log files in order to get
all those out.  There is no other source for this information.

A lot of convenience functions from AUCTeX are used that are not
actually related to TeX at all.  The user interface parts are not done
in any way independent from the AUCTeX user interface.

> Would preview-latex be of any use with Texinfo?
> Maybe not, since generally there are few equations in Texinfo.

The LilyPond (music typesetter) documentation is generated via Texinfo.
There are probably not all that many people using the Info version with
graphical images but it beats the pants off the generally used online
HTML version (all the web pages, not just the manuals, are also
generated from Texinfo).

But the _only_ usable reader for the Info version with graphics is
Emacs.  Yelp (GNOME help viewer) purports to support images in Info but
does not scale to ten thousands of images.  One never gets across the
"Loading" message.

Now the LilyPond documentation is probably the best use of images in
Info anywhere.  Still I would not want to bet my life savings on more
than a dozen people actively using the Info variants of those manuals.

But while few people actually use the Info output format, lots more use
Texinfo with other backends.  I could imagine the Texinfo/preview-latex
combination to be popular with our documentation editors even though
most of them probaly have never looked at Info output and consider HTML
and PDF the "normal" output formats.

-- 
David Kastrup