Re: Using org-latex-preview in other major modes

[Karthik Chikmagalur <karthikchikmagalur@gmail.com>]

> Anyways, before I put this off for much longer, there is some more code
> attached. Live previews (and general environments) work now, and besides
> the above mentioned points there were no new surprises waiting—at least
> for getting the basic functionality to work.

Thank you for the update!  This looks promising.  I'll test it when I
have time.

> I did notice that precompilation being a bit flaky. In the end, this
> was the result of importing local packages; with the precompilation
> happening somewhere in /tmp/, access to these files wasn't given.
> haven't looked too closely into this—and it's probably a use-case
> that's specific to LaTeX-mode—but it seems worth considering

Sorry, I should have mentioned this in my original write-up.  There is a
reason for this, as explained below.  This issue should not be happening
in most cases though, so I'll need more details to help.

> (lots of people carry one big style file around that they include in
> all of their projects).

This is true of Org mode files that are intended for LaTeX export too,
but we avoid this problem in Org.

1. Why we precompile in /tmp:

   Precompilation is a blocking operation, so we want to do it as
   infrequently as possible. Imagine if LaTeX previews in every Org
   buffer/file you opened required a precompile step that blocked Emacs
   for 3 seconds.

   Precompiled dump files are identified by a hash that includes the
   preamble and a default-directory. If we precompile in /tmp (or some
   other fixed directory), we can reuse dump files for all Org buffers
   that have the same preamble, irrespective of where they're located.

   Precompiled files are stored in org-persist and don't expire for a
   long time.  So we'd like to avoid generating loads of them, and reuse
   them whenever possible.

   1a. Why is precompilation a blocking operation?

       It doesn't have to be, but including it in the async chain is a
       little annoying.  It can be made async in the future.

2. What happens if the user includes a directory-local .sty, .cls or
   other tex files in the header?

   When precompiling, we check the header to see if it has an \input{}
   or \include{} statement.  If it does, we assume that there are local
   dependencies and precompile it in the default-directory.  See
   org-latex-preview--create-tex-file for the implementation of this
   logic.

   Is there some other common way that a LaTeX file can have local
   dependencies?

3. How to force precompilation to occur in the default-directory instead
   of in /tmp:

   Based on 1 and 2, the easiest way would be to add an \input{} or
   \include{} statement to the preamble. The current test is very
   simple, you can even place it in a LaTeX comment and it should work.

Karthik