Karthik Chikmagalur <[email protected]> writes:
> I've added more commits to the branch addressing these comments:
Thanks!
> - org-latex-and-related-regexp now consults
> org-highlight-latex-matchers. If that is nil, it falls back to
> (plist-get org-latex-preview-appearance-options :matchers)
Good idea to mark those places with FIXME for future removal.
They will need to go after the obsolete variable is removed, but it may
be tricky to find this compatibility code as it does not use obsolete
variable name.
>>> - The latexmk command is wrong for use with org-latex-preview, it needs
>>> to generate a dvi, not a pdf.
>>
>> How does it work now then?
>
> I am not sure.
I found why.
We have
"latexmk -f -pdf -latex -interaction=nonstopmode -output-directory=%o %f"
where
-latex This sets the generation of dvi files by latex, and turns off the
generation of pdf and ps files.
-pdf Generate pdf version of document using pdflatex. (If you wish
to use lualatex or xelatex, you can use whichever of the options -pdflua,
-pdfxe, -lualatex or -xelatex ap‐
plies.) To configure latexmk to have such behavior by default,
see the section on "Configuration/initialization (rc) files".
In our command -latex overrides the effect of -pdf.
So, -pdf is redundant there and means nothing.
>>> - The bigger problem is that the org-latex-preview API does not support
>>> running LaTeX multiple times, so if latexmk is not available this will
>>> fail. This is unfortunately not easy to fix.
>>
>> Does it mean that
>>
>> :latex-compiler list of LaTeX commands, as strings or a function.
>> Each of them is given to the shell.
>> Place-holders \"%t\", \"%b\" and \"%o\" are
>> replaced with values defined below.
>> When a function, that function should accept the
>> file name as its single argument.
>>
>> in the docstring of `org-latex-preview-process-alist' is not accurate?
>> Is function also not supported?
>
> Yes, both lists of commands and functions are unsupported.
>
> The docstring needs to be changed, or support for these things needs to
> be added to org-latex-preview--tex-compile-async. In this function you
> can see what we are doing right now inside a let-binding:
>
> (tex-compile-command-fmt
> (pcase (plist-get extended-info :latex-compiler)
> ((and (pred stringp) cmd) cmd)
> ((and (pred consp) cmds)
> (when (> (length cmds) 1)
> (warn "Preview :latex-compiler must now be a single command. %S will
> be ignored."
> (cdr cmds)))
> (car cmds))))
>
> I think we meant to do something about this later and lost track of it.
>
> My understanding of this issue today is the following:
>
> - the default :latex-compiler and :image-converter commands in
> org-latex-preview-process-alist are very finely tuned for
> performance/speed to support live previews.
That's fine. We do not expect the users to customize this unless they
really need to.
> - If you customize :latex-compiler, you will also have to customize
> :image-converter carefully to be compatible. I think the functions
> --tex-compile-async and --image-extract-async make some assumptions
> that make it difficult to customize :latex-compiler and
> :image-converter at all -- the process is inherently more complex than
> the previous method of calling org-compile-file synchronously.
I do not see anything obvious in --image-extract-async.
--tex-compile-async has `org-latex-preview--latex-preview-filter', but
that one should seemingly be ok when preview.sty is not used.
When preview.sty is used, I am not sure.
As for compatibility, I think it is expected and it is the same on main.
> - I have tested that using latexmk in the :latex-compiler does indeed
> work (with no changes to :image-converter), but I remember that I had
> to be careful to choose a very specific set of CLI arguments.
>
> I don't know what the way forward should be. I haven't changed the
> docstring of org-latex-preview-process-alist yet.
I'd like to figure out what exactly are additional assumptions in the
new code.
>>> The png path works if I ignore org-babel-latex-process-alist and reuse
>>> org-latex-preview-process-alist.
>>
>> It is important that we use latexmk/triple latex there as it will allow
>> resolving references. Let's discuss what can be done.
>
> Based on the above, latexmk will work, but only with a specific set of
> CLI arguments. If they want to customize org-babel-latex-process-alist,
> it's going to be beyond the ability of most users to figure out what
> these arguments should be.
Why? I think we ourselves need to figure out first what exactly are the
requirements.
--
Ihor Radchenko // yantar92,
Org mode maintainer,
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>
