Karthik Chikmagalur <[email protected]> writes:
>>> (processing-info
>>> (nconc (list :latex-processor latex-processor)
>>> (and latex-preamble (list :latex-header latex-preamble))
>>> (alist-get processing-type org-latex-preview-process-alist)))
>>>
>>> Should org-latex-preview-process-alist have a :latex-header field? I'm
>>> not sure what its purpose is.
>>
>> It is in the docstring:
>>
>> :latex-header list of strings, the LaTeX header of the snippet file.
>> When nil, the fallback value is used instead, which is
>> controlled by option `org-latex-preview-preamble',
>> `org-latex-default-packages-alist' and
>> `org-latex-packages-alist', which see.
>
> Yes. I was wondering if it made sense to keep it.
> org-latex-preview-process-alist is no longer an alias of the old variable,
> and we can decide if it makes sense to include the :latex-header
> specification here as an option.
>
> Personally, I don't see a need for it.
Maybe some exotic compilers need dedicated header.
For example, recall
\def\pgfsysdriver{pgfsys-tex4ht.def}
from ob-latex that is needed for htlatex.
>>>>> (if (pcase (plist-get extended-info :processor)
>>>>> ('dvisvgm (eq exit-code 252)) ; Input file does not
>>>>> exist.
>>>>> ('dvipng ; Same check, just a bit more involved.
>>>>> (and (eq exit-code 1)
>>>>> (with-current-buffer
>>>>> (save-excursion
>>>>> (goto-char (point-min))
>>>>> (search-forward ": No such file or
>>>>> directory" nil t))))))
>>>>> (propertize org-latex-preview--latex-log 'face 'warning)
>>>>> (propertize org-latex-preview--image-log 'face 'warning))
>>>>
>>>> More generally, why do you need to guess the buffer here and do not use
>>>> _buf instead?
>>>
>>> I am now using _buf as the process buffer to search in for the dvipng
>>> branch. But the problem that this is trying to solve is different: when
>>> the image-extract-async task fails, we don't know if it failed because
>>> dvipng failed to convert the dvi file to images, or because the dvi file
>>> itself was not generated. If the dvi file itself was not generated, the
>>> user
>>> should look in org-latex-preview--latex-log, else in
>>> org-latex-preview--image-log. This is what the if statement above is
>>> determining.
>>
>> But this is in
>> (plist-put (cddr img-extract-async) :failure
>> (list
>> #'org-latex-preview--failure-callback
>> #'org-latex-preview--cleanup-callback))
>> So, this should only trigger when image conversion fails, which implies
>> that .dvi files has been generated.
>> What do I miss?
>
> Two things:
>
> 1. preview.sty can fail with exit-code 1 even when the run is
> successful. This is by design for preview.sty, details are in its
> manual. For this reason we have:
>
> (plist-put (cddr tex-compile-async) :success img-extract-async)
> (plist-put (cddr tex-compile-async) :failure img-extract-async)
>
> implying we always run the image extractor, even if the tex compilation
> "fails". So when the image converter fails, we don't know if it was
> because the tex compilation failed and no dvi was produced.
> 2. dvipng has a --follow option that we use, where it is started right
> away, before any dvi files have been produced. This is for speed.
> dvipng can read a partially produced dvi file and start producing images
> for completed pages. This is why the dvipng route is much faster than
> dvisvgm -- dvipng previews can feel instant if you have a small LaTeX
> preamble.
>
> But in this context it means image-extract-async runs whether or not the
> LaTeX process fails.
These caveats would be nice to put somewhere in the commentary.
Because it is bending :failure/:success design quite a bit.
--
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>
