Using org-latex-preview in other major modes

Using org-latex-preview in other major modes

[Tony Zorman]

[-- Attachment #1: Type: text/plain, Size: 1632 bytes --]

Hi,

I'm interested in adjusting org-latex-preview to work in other major
modes (most notably LaTeX-mode itself, so one can get rid of preview.el).
On the advice of Karthik (Cc'd) I'll move the discussion from private
mails to this list, so more people who might be interested can join in.

I've prodded the code a little bit and, mostly just following [1],
managed to implement basic previews in a relatively straightforward
fashion. Attached is a proof-of-concept—aptly named
latex-latex-preview.el :) The main user facing functions so far are
'latex-latex-preview' to preview the maths fragment at point, and
'latex-latex-preview-region' to preview all fragments in a region. Both
functions currently ignore things like numbered equations and
environments, though both do not seem exceptionally difficult to add
back in.

There's also a stub 'latex-latex-preview-auto-mode' minor mode. Stepping
in and out of already rendered environments works fine, with the preview
being regenerated if needed; only the implementation of
'org-latex-preview-auto--regenerate-overlay' had to change for that. The
mode does not currently feature live-previews. The innards of
'org-latex-preview-auto--detect-fragments-in-change' and
'org-latex-preview-live--setup' look a bit more org-specific, with
queries to 'org-element-*' functions all over the place, but all of that
looks fixable—at least from afar. I will continue prodding the code a
little bit and will report back with any bumps that are hit along the
way.

  Tony

[1]: https://abode.karthinks.com/org-latex-preview/latex-preview-everywhere.html


[-- Attachment #2: latex-latex-preview.el --]
[-- Type: application/emacs-lisp, Size: 7445 bytes --]

[-- Attachment #3: Type: text/plain, Size: 44 bytes --]


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

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

[Ihor Radchenko]

Tony Zorman <mail@tony-zorman.com> writes:

> I'm interested in adjusting org-latex-preview to work in other major
> modes (most notably LaTeX-mode itself, so one can get rid of preview.el).
> On the advice of Karthik (Cc'd) I'll move the discussion from private
> mails to this list, so more people who might be interested can join in.
> ...
> [1]: https://abode.karthinks.com/org-latex-preview/latex-preview-everywhere.html

Abstracting away previews is certainly welcome.
RMS explicitly asked Org mode team to work towards this goal:
https://list.orgmode.org/E1kIkxv-0007iy-Av@fencepost.gnu.org/

Ideally, we should have Org-independent library that does the previews,
and an Org-specific code that re-uses this library. Eventually, we can
move the generic library to Emacs core.

We may go even further, and extend the previews to be not just for
LaTeX. Might as well preview html/image links/pdf links/etc.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Karthik Chikmagalur]

> Abstracting away previews is certainly welcome.
> RMS explicitly asked Org mode team to work towards this goal:
> https://list.orgmode.org/E1kIkxv-0007iy-Av@fencepost.gnu.org/

I agree with RMS about this, and this was on our minds when we wrote
org-latex-preview.  The basic previewing process is explicitly written
to be Org-agnostic, but we weren't as rigorous when adding the fancier
features (like live previews).

> Ideally, we should have Org-independent library that does the previews,
> and an Org-specific code that re-uses this library. Eventually, we can
> move the generic library to Emacs core.

Here is the plan Timothy and I have discussed:

1. Merge org-latex-preview in its current state and continue to fix
bugs/edge cases.
2. Write an external package reimplementing in a more generic way the
parts of the API that are Org-specific.  This external package will
depend (heavily) on org-latex-preview.
3. Solicit from the community integrations of this with other
major-modes using this generic API.
4. Once this API is stable, replace the corresponding parts of
org-latex-preview.
5. Propose moving everything but the Org-specific parts to a
`latex-preview.el' package included with Emacs.

From Tony's proof of concept, I think step 2 might be unnecessary and we
can incrementally modify org-latex-preview instead.

> We may go even further, and extend the previews to be not just for
> LaTeX. Might as well preview html/image links/pdf links/etc.

I agree in principle but I think this is difficult to do with
org-latex-preview because the async process chain and overlay handling are
highly tuned for low-latency LaTeX processing.[1] 

I do think Emacs could use a generic link-preview package, with an
org-link-preview adapter for Org mode.

Karthik

[1]: As low-latency as possible from Emacs without modifying
the LaTeX compiler or image renderer, as for example TeXpresso
does. https://github.com/let-def/texpresso

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

[Ihor Radchenko]

Karthik Chikmagalur <karthikchikmagalur@gmail.com> writes:

>> We may go even further, and extend the previews to be not just for
>> LaTeX. Might as well preview html/image links/pdf links/etc.
>
> I agree in principle but I think this is difficult to do with
> org-latex-preview because the async process chain and overlay handling are
> highly tuned for low-latency LaTeX processing.[1] 
>
> I do think Emacs could use a generic link-preview package, with an
> org-link-preview adapter for Org mode.

What I had in mind is something yet more generic:

1. preview.el abstracting away an API to toggle previews in
   buffer/region and display previews in separate buffer/echo area.
   It will provide customization on what kinds of previews are to be
   displayed; and the underlying backends will add themselves to some
   kind of hook that will do the actual work.

2. latex-preview.el with generic API to preview latex fragments in
   particular (or maybe even generic fragments that require to run
   convertor code -> image).

3. org-latex-preview with Org specific code.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Karthik Chikmagalur]

>> I'm interested in adjusting org-latex-preview to work in other major
>> modes (most notably LaTeX-mode itself, so one can get rid of preview.el).
>> On the advice of Karthik (Cc'd) I'll move the discussion from private
>> mails to this list, so more people who might be interested can join in.
>> ...
>> [1]: https://abode.karthinks.com/org-latex-preview/latex-preview-everywhere.html
>
> Abstracting away previews is certainly welcome.
> RMS explicitly asked Org mode team to work towards this goal:
> https://list.orgmode.org/E1kIkxv-0007iy-Av@fencepost.gnu.org/

I recently spent some time on this feature (LaTeX previews in all
major-modes) and produced a few prototypes.  You can see some demos in

https://www.youtube.com/watch?v=u44X_th6_oY [1]

The way support for other major modes works right now is based on the
following observation: The `org-latex-preview' feature uses a tiny
subset of the `org-element' API.  Specifically, it uses only the
functions

- `org-element-context'
- `org-element-property', referring to the properties :value,
  :begin and :end, and optionally :post-blank and :post-affiliated
- `org-element-type', which returns either latex-fragment,
  latex-environment or any other symbol

In addition, it uses two functions to generate the preamble and find
section bounds:

- `org-latex-preview--get-preamble'
- `org-latex-preview--section-bounds'

If a major-mode can provide drop-in replacements for all these
functions, we can run org-latex-preview -- all of it, including live
previews etc, in that mode.[2]

I can share the full code in a dev branch soon after cleaning it up.  In
this email, I was hoping to solicit some feedback on the Emacs-wide API
for this, which I describe below:

----------------------

I made calls to the above `org-elment-*' functions "pluggable", by
storing these functions in buffer-local variables named

- `org-latex-preview--fcontext'
- `org-latex-preview--fproperty'
- `org-latex-preview--ftype'

and so on.  Instead of calling `org-element-*' like this:

(org-element-property :value (org-element-context))

org-latex-preview now uses

(funcall org-latex-preview--fproperty
         :value
         (funcall org-latex-preview--fcontext))

A major mode can register these handlers with org-latex-preview like
this (example for previews in LaTeX-mode, adapted from Tony's code):

(setf (alist-get 'LaTeX-mode org-latex-preview-interfaces)
      `(:preamble ,#'latex-latex-preview--make-preamble
        :section  ,#'latex-latex-preview-section-bounds
        :context  ,#'latex-latex-preview-context
        :type     ,#'latex-latex-preview-type
        :property ,#'latex-latex-preview-property))
        
See [1] for the definition of these `latex-latex-*' functions.

These functions in `org-latex-preview-interfaces' are set as the values
of the various `org-latex-preview--f*' variables during the first call
to org-latex-preview in the buffer. There is no continuous runtime
dispatch based on the major-mode.  (Since we run many of these functions
in the `after-change-functions' hook, we really want to avoid runtime
dispatch.)

Is this the best way to go about this?

Karthik

[1]: To see what the "adapter" code looks like for different modes, here
are some examples:
https://paste.karthinks.com/ac64169c-prog-latex-preview.el.html
https://paste.karthinks.com/6ba26238-calc-latex-preview.el.html
https://paste.karthinks.com/44930b4e-latex-latex-preview.el.html

[2]: This is without handling accurate numbering.  Numbering requires a
couple more replacement functions that I can describe if required.

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

[Ihor Radchenko]

Karthik Chikmagalur <karthikchikmagalur@gmail.com> writes:

>> Abstracting away previews is certainly welcome.
>> RMS explicitly asked Org mode team to work towards this goal:
>> https://list.orgmode.org/E1kIkxv-0007iy-Av@fencepost.gnu.org/
>
> I recently spent some time on this feature (LaTeX previews in all
> major-modes) and produced a few prototypes.  You can see some demos in
>
> https://www.youtube.com/watch?v=u44X_th6_oY [1]

Thanks!
Also, talking about calc previews... there is https://github.com/johnbcoughlin/calctex

> The way support for other major modes works right now is based on the
> following observation: The `org-latex-preview' feature uses a tiny
> subset of the `org-element' API.  Specifically, it uses only the
> functions
>
> - `org-element-context'
> - `org-element-property', referring to the properties :value,
>   :begin and :end, and optionally :post-blank and :post-affiliated
> - `org-element-type', which returns either latex-fragment,
>   latex-environment or any other symbol

I think that it will be better to reuse thingatpt.el to retrieve object
boundaries: fragments and sections.

> In addition, it uses two functions to generate the preamble and find
> section bounds:
>
> - `org-latex-preview--get-preamble'
> - `org-latex-preview--section-bounds'

For preamble, we may simply use buffer-local variable.
Something like
(defvar-local latex-preview-make-preamble-function #'latex-preview-default-preamble ...)

Then, major modes may set it as needed.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Karthik Chikmagalur]

Hi Tony,

Just tried it out, it's very promising!  Thanks for taking the initiative
on this.

> I've prodded the code a little bit and, mostly just following [1],
> managed to implement basic previews in a relatively straightforward
> fashion. Attached is a proof-of-concept—aptly named
> latex-latex-preview.el :) The main user facing functions so far are
> 'latex-latex-preview' to preview the maths fragment at point, and
> 'latex-latex-preview-region' to preview all fragments in a region. Both
> functions currently ignore things like numbered equations and
> environments, though both do not seem exceptionally difficult to add
> back in.

There are two issues with numbering:
- providing an Org-agnostic API point to attach a numbering table to, and
- calculating the new numbering table in LaTeX (or other major-modes).

For The first issue, we need a way to provide an updated numbering table
during the auto-regeneration of edited fragments.  Currently this is
done implicitly by calling `org-latex-preview--place-from-elements' from
the `--regenerate-overlay` function.

The second requires fast numbering table updates.  We do it in Org by
mapping over the org-element cache (see
`org-latex-preview--get-numbered-environments').  Even this is too slow
sometimes, so we suspend numbering updates when live-previewing until
the cursor exits the fragment.  Parsing the LaTeX buffer from point to
the end when (re)generating each preview is going to be too slow, so
you'll have to create some kind of cache and update it incrementally.

> There's also a stub 'latex-latex-preview-auto-mode' minor mode. Stepping
> in and out of already rendered environments works fine, with the preview
> being regenerated if needed; only the implementation of
> 'org-latex-preview-auto--regenerate-overlay' had to change for that.

This was a pleasant surprise, I was expecting more trouble here.

> The mode does not currently feature live-previews. The innards of
> 'org-latex-preview-auto--detect-fragments-in-change' and
> 'org-latex-preview-live--setup' look a bit more org-specific, with
> queries to 'org-element-*' functions all over the place, but all of
> that looks fixable—at least from afar. I will continue prodding the
> code a little bit and will report back with any bumps that are hit
> along the way.

`org-latex-preview-auto--detect-fragments-in-change' is written for
speed. It only does quick text-matching and is thus mostly Org-agnostic,
except for a call to a numbering calculation near the end.  This should
be easy to adapt.  The problem is the function it calls,
`org-latex-preview-auto--maybe-track-element-here', which finds the
bounds of the inserted LaTeX fragment using org-element and
conditionally sets up a preview overlay.  You will need an equivalent of
this for LaTeX-mode.

Since you have auto-mode working already, live previews should be quite
easy to add.  From what I can see, you only need to provide your own
`org-latex-preview-live--ensure-overlay'.  This function creates the
preview overlay next to or under the LaTeX fragment.  All the other live
preview code only changes overlay properties or calls
`--regenerate-overlay`, which you've already implemented.

Karthik

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

[Tony Zorman]

On Sun, Apr 07 2024 10:48, Karthik Chikmagalur wrote:
> [… 14 lines elided …]
>
> There are two issues with numbering:
> - providing an Org-agnostic API point to attach a numbering table to, and
> - calculating the new numbering table in LaTeX (or other major-modes).
>
> For The first issue, we need a way to provide an updated numbering table
> during the auto-regeneration of edited fragments.  Currently this is
> done implicitly by calling `org-latex-preview--place-from-elements' from
> the `--regenerate-overlay` function.
>
> The second requires fast numbering table updates.  We do it in Org by
> mapping over the org-element cache (see
> `org-latex-preview--get-numbered-environments').  Even this is too slow
> sometimes, so we suspend numbering updates when live-previewing until
> the cursor exits the fragment.  Parsing the LaTeX buffer from point to
> the end when (re)generating each preview is going to be too slow, so
> you'll have to create some kind of cache and update it incrementally.

Thanks for taking a look! It indeed seems that caching will be the most
work to properly implement. However, I'm quite happy to not care about
numbers for now and make sure the other stuff works correctly first
before tackling this.

> [… 14 lines elided …]
>
> `org-latex-preview-auto--detect-fragments-in-change' is written for
> speed. It only does quick text-matching and is thus mostly Org-agnostic,
> except for a call to a numbering calculation near the end.  This should
> be easy to adapt.  The problem is the function it calls,
> `org-latex-preview-auto--maybe-track-element-here', which finds the
> bounds of the inserted LaTeX fragment using org-element and
> conditionally sets up a preview overlay.  You will need an equivalent of
> this for LaTeX-mode.
>
> Since you have auto-mode working already, live previews should be quite
> easy to add.  From what I can see, you only need to provide your own
> `org-latex-preview-live--ensure-overlay'.  This function creates the
> preview overlay next to or under the LaTeX fragment.  All the other live
> preview code only changes overlay properties or calls
> `--regenerate-overlay`, which you've already implemented.

Besides `org-latex-preview-auto--maybe-track-element-here`, I was mostly
talking about `org-latex-preview-live--src-buffer-setup` and
`org-latex-preview-live--ensure-overlay`, which I think will be the main
targets. The latter seems to be quite a straightforward translation
(especially my current constraints of not caring about environments),
but the former seems to require a bit more work. Then again, maybe I'm
being too negative—after taking another quick look at the code I think
you're right in that this should not be impossible to overcome.

I'll try to conjure up some time this week to get live previews up and
running; will report back if I hit any unforeseen major bumps.

  Tony

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

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

[Karthik Chikmagalur]

> Thanks for taking a look! It indeed seems that caching will be the most
> work to properly implement. However, I'm quite happy to not care about
> numbers for now and make sure the other stuff works correctly first
> before tackling this.

Sure, this is a disproportionate amount of work for a minor feature.  I
suggest setting `org-latex-preview-numbered' to nil, FWIW.  The previews
look better this way.

> Besides `org-latex-preview-auto--maybe-track-element-here`, I was mostly
> talking about `org-latex-preview-live--src-buffer-setup` and
> `org-latex-preview-live--ensure-overlay`, which I think will be the main
> targets. The latter seems to be quite a straightforward translation
> (especially my current constraints of not caring about environments),

You can ignore `org-latex-preview-live--src-buffer-setup', this is for
previewing when using `org-edit-special' (C-c '), which does not apply
to any other major mode.  So `org-latex-preview-live--ensure-overlay' is
the only function you need to rewrite, which should be easy.

Keep us updated. Good luck!

Karthik

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

[Tony Zorman]

On Sun, Apr 07 2024 23:36, Karthik Chikmagalur wrote:
> You can ignore `org-latex-preview-live--src-buffer-setup', this is for
> previewing when using `org-edit-special' (C-c '), which does not apply
> to any other major mode.  So `org-latex-preview-live--ensure-overlay' is
> the only function you need to rewrite, which should be easy.

Oh, indeed, you are right; seems like it only looked intimidating! I
quickly hacked this in just now, and it works just fine.

As a very brief summary, one currently needs to—in addition to supplying
a preamble and a way to recognise maths and environments—patch the
following functions:

  · org-latex-preview--place-from-elements
  · org-latex-preview-auto--regenerate-overlay 
  · org-latex-preview-auto--maybe-track-element-here
  · org-latex-preview-live--ensure-overlay

The last two are only needed for the "live" part of the live previews to
work.

I will clean the code up a little bit (hopefully by the weekend, but no
promises), and try to add support for LaTeX environments instead of just
maths. I reckon that once this is finished one can get a pretty good
idea in which direction org-latex-preview.el would need to be nudged to
more easily facilitate this kind of integration. After that I guess
there's still the issue of caching and numbering, but I'll cross that
bridge once we get to it :)

  Tony

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

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

[Tony Zorman]

[-- Attachment #1: Type: text/plain, Size: 1338 bytes --]

On Tue, Apr 09 2024 22:06, Tony Zorman wrote:
> As a very brief summary, one currently needs to—in addition to supplying
> a preamble and a way to recognise maths and environments—patch the
> following functions:
>
>   · org-latex-preview--place-from-elements
>   · org-latex-preview-auto--regenerate-overlay 
>   · org-latex-preview-auto--maybe-track-element-here
>   · org-latex-preview-live--ensure-overlay
>
> The last two are only needed for the "live" part of the live previews to
> work.
>
> I will clean the code up a little bit (hopefully by the weekend, but no
> promises),

Whoops!

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.

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. I
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 (lots of people
carry one big style file around that they include in all of their
projects).

  Tony


[-- Attachment #2: latex-latex-preview.el --]
[-- Type: application/emacs-lisp, Size: 10856 bytes --]

[-- Attachment #3: Type: text/plain, Size: 44 bytes --]


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

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

[Karthik Chikmagalur]

> 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

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/