From: Nicolas Goaziou <n.goaziou@gmail.com>
To: Nick Dokos <ndokos@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Minor problems with dvipng latex image preview
Date: Sat, 25 May 2013 22:20:24 +0200 [thread overview]
Message-ID: <877gim6cc7.fsf@gmail.com> (raw)
In-Reply-To: <87txltz8c3.fsf@pierrot.dokosmarshall.org> (Nick Dokos's message of "Thu, 23 May 2013 17:37:16 -0400")
Nick Dokos <ndokos@gmail.com> writes:
> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>> Anyway, in a nutshell, your proposal is to:
>>
>> - add a custom variable, e.g., `org-latex-dvi-process-options' (which
>> library should it belong to?)
>
> Unless it would make sense to toss the whole dvipng thing overboard and
> just keep imagemagick.
I'm not sure there is a really good reason to drop it. Is it inferior in
some way?
Also, imagemagick is not optimal either. Since it uses
`org-latex-pdf-process', "pdflatex" is called three times by default,
which is unnecessary for a short snippet.
So, both dvipng and imagemagick should have a variable to set the
program to call, along with its arguments.
>> - modify `org-latex-listings' docstring (in particular, add third
>> elements and new custom variable)
>
> I'm not sure any more that it can all be explained clearly in the
> docstring (at least I've been trying different mental gyrations and I
> have not come up with anything satisfactory). So maybe the thing to do
> is add a page to worg and a pointer to it in the docstring. If that's
> acceptable, I volunteer to write the worg page (at least the initial
> version).
A worg page can't hurt, but a URL in the docstring is not very handy
either. It also defeats the "self-documenting" part of Emacs.
> As a separate issue, I proposed some debugging aids:
>
>> - add a custom variable, e.g., `org-latex-dvi-process-debug', which,
>> when non-nil asks to leave produced "tex" file.
>>
>
> ... and a call-process-log function that logs the command in *Messages*
> before executing it with call-process (or something more or less
> equivalent). It would be used wherever call-process is used now.
>
> I would actually propose that the debug variable inhibit the deletion
> of intermediate files everywhere, not just in latex preview.
Some parts of Org already have their own debug variable (see
`org-export-async-debug'). A meta debug variable would not be optimal,
would it?
Regards,
--
Nicolas Goaziou
next prev parent reply other threads:[~2013-05-25 20:20 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-19 22:27 Minor problems with dvipng latex image preview Nick Dokos
2013-05-22 19:03 ` Nicolas Goaziou
2013-05-23 6:21 ` Nick Dokos
2013-05-23 13:21 ` Nicolas Goaziou
2013-05-23 16:06 ` Nick Dokos
2013-05-23 16:53 ` Nicolas Goaziou
2013-05-23 21:37 ` Nick Dokos
2013-05-25 20:20 ` Nicolas Goaziou [this message]
2013-05-26 6:38 ` Nick Dokos
2013-05-30 15:12 ` Nicolas Goaziou
2013-05-30 15:25 ` Nick Dokos
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877gim6cc7.fsf@gmail.com \
--to=n.goaziou@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=ndokos@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).