Re: [O] Minor problems with dvipng latex image preview

Nicolas Goaziou <n.goaz...@gmail.com> writes:

>> OK, that works - I didn't know about the three-element list
>> form. Thanks!
>
> The surprising part of that third element is that it is assumed to be
> non-nil when missing (see org-latex-packages-to-string').
>

Yes, presumably in the name of backward compatibility and "least
surprise": if one uses the two-element form, one gets the package
included in both export and previews, which is probably what is
wanted in general (although minted is something of an exception).

>> Perhaps the docstring for org-latex-listings should include
>> the three-element list form, with a pointer to the
>> org-latex-packages-alist doc for more details.
>
> The docstring already contains two references to
> org-latex-packages-alist'.  Wouldn't suggesting to insert
>
>   (add-to-list 'org-latex-packages-alist '("" "minted" nil))
>
> be confusing, since we don't provide a third element for "listings" and
> "color" packages? Well, unless we provide the element for the three of
> them (t for the first two, and nil for the last).
>

Yes, it's not particularly easy to explain. But if one copies the code
from the docstring verbatim, one can slam into the problem and it is not
easy to debug.

>> There is also a (perhaps unlikely) scenario where this is not enough:
>> previewing typeset code where I *want* to use minted:
>>
>> * Code
>>
>> \begin{minted}{c} printf("Hello world\n"); \end{minted}
>
> In that case, I suggest to use imagemagick' for the conversion, since
> it relies on org-latex-pdf-process' value (and is therefore
> customizable).
>

I learnt quite a bit from this discussion (thank you!), but I'm still a
latex call. Why is that? Too many customizations? dvipng should be
deprecated?  Too many twisty passages to explain?

BTW, I found myself wishing for some debugging aid along the following
lines: an option to keep the .tex file produced (it *is* kept in case of
error, but sometimes it would be nice to look at it even if there is no
error), and a message in *Messages* with the complete command that
call-process is executing: that way, one can easily execute the command
by hand. One can always use the debugger for this, but that feels like
the proverbial elephant gun in search of a fly.

--
Nick