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/
