[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Using org-latex-preview in other major modes
From: |
Karthik Chikmagalur |
Subject: |
Re: Using org-latex-preview in other major modes |
Date: |
Sun, 21 Apr 2024 20:41:15 -0700 |
> 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