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

[Nick Dokos]

Nicolas Goaziou <address@hidden> 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
bit puzzled about your reluctance that custom options be added to the
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