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

[Tony Zorman]

On Sun, Apr 21 2024 20:41, Karthik Chikmagalur wrote:
>> 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?

\usepackage accepts relative paths, although I think it will generate a
warning since the package called will provide «pkg» instead of
.relative/path/to/«pkg». Either way, it's not uncommon to see things
like

    \usepackage[opt1, opt2=lf]{style/nested/too/deeply/style}

Modulo Windows, one might check for slashes in \usepackage invocations,
since I don't think TeX packages can have those.

(Users *should* really add /path/to/«pkg» to LaTeX's search path, but
that will never happen :))

> 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.

This does indeed work; thanks!

  Tony

-- 
Tony Zorman | https://tony-zorman.com/