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: Thu, 30 May 2013 17:12:06 +0200 [thread overview]
Message-ID: <877gigfqnt.fsf@gmail.com> (raw)
In-Reply-To: <87sj1amej5.fsf@pierrot.dokosmarshall.org> (Nick Dokos's message of "Sun, 26 May 2013 02:38:38 -0400")
Hello,
Nick Dokos <ndokos@gmail.com> writes:
> I wouldn't say inferior, although the dvipng implementation is slightly
> more brittle than the imagemagick one (imo, of course). But it is two
> implementations where one would suffice (Windows might present problems
> however: I don't know the availability of dvipng/imagemagick on that
> platform - I believe they are both available on MacOS, but I could be
> wrong).
What about asking, in a fresh thread, the users about it, then? FWIW,
I'm all for anything related to spring cleaning.
>> 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.
> Agreed again (about the self-documenting part: not sure about the URL
> not being very handy), but some things are just too fiddly to fit into a
> few sentences. I have now written a document of 335 lines (still not
> done and only covering the options available today, but I am trying to
> provide enough context to make it stand on its own): I may be suffering
> from Pascal's syndrome ("Forgive the length of this letter; I did not
> have the time to make it shorter") and I do tend to be verbose in
> explanations (as some people on this list can probably testify), but I'm
> not sure I can shorten it by much, even if I suddenly turn into
> Hemingway - yeah, I wish :-)
>
> In any case, a note like "If you get into trouble or you want to know
> more, see FOO for the gory details" does not seem too bad to me.
So be it. Tell me when the worg page is ready, I'll update the docstring
accordingly.
> Optimal in what sense? Also, I'm not sure what you mean by a "meta
> debug" variable. I was thinking of a more global debug variable (it
> would e.g. subsume the role of org-export-async-debug), but you
> are right that it's more complicated than that: e.g. there is the
> question of what all the intermediate files are and where they are
> located.
"debug" can cover many different cases, and a "meta", i.e. global,
variable would have to explain all of them in its docstring. In the end,
the net gain for adding such a variable is not clear (besides
discoverability, but is it important for this kind of variable?).
> That's why I wanted a log message in *Messages*: I could then say "keep
> all intermediate files" by turning on the variable, carry out the
> operation and then look in *Messages* to find out where those files are
> - no mucking around through the sources. What I do now is find the
> function that produces the file(s), and either edebug it, break at (or
> just after) the call-process call site and evaluate the variables to
> figure out where everything is, then go look at them; or add a (debug)
> call just after and otherwise proceed the same way.
>
> It's not too bad, but I like systems that can tell me what they are
> doing, so if the need arises, I can easily figure out what went wrong.
Improvements to the debug system need to be discussed thoroughly in
order to set up complete specifications (I don't think it's just about
latex snippets).
This cannot happen as a side note in a thread between you and me. If you
think it is important enough, please initiate the process in a new
thread.
Regards,
--
Nicolas Goaziou
next prev parent reply other threads:[~2013-05-30 15:12 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
2013-05-26 6:38 ` Nick Dokos
2013-05-30 15:12 ` Nicolas Goaziou [this message]
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=877gigfqnt.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).