From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Dokos Subject: Re: Minor problems with dvipng latex image preview Date: Sun, 26 May 2013 02:38:38 -0400 Message-ID: <87sj1amej5.fsf@pierrot.dokosmarshall.org> References: <871u9238sl.fsf@pierrot.dokosmarshall.org> <87ehcyg7mg.fsf@gmail.com> <877giq1aj1.fsf@pierrot.dokosmarshall.org> <87d2shrfwj.fsf@gmail.com> <87y5b5znnu.fsf@pierrot.dokosmarshall.org> <87wqqptz7k.fsf@gmail.com> <87txltz8c3.fsf@pierrot.dokosmarshall.org> <877gim6cc7.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:34764) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UgUba-0004jT-5y for emacs-orgmode@gnu.org; Sun, 26 May 2013 02:39:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UgUbT-0004S6-OE for emacs-orgmode@gnu.org; Sun, 26 May 2013 02:38:58 -0400 Received: from plane.gmane.org ([80.91.229.3]:50678) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UgUbT-0004S1-Db for emacs-orgmode@gnu.org; Sun, 26 May 2013 02:38:51 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UgUbS-0005ZY-DF for emacs-orgmode@gnu.org; Sun, 26 May 2013 08:38:50 +0200 Received: from pool-108-7-96-134.bstnma.fios.verizon.net ([108.7.96.134]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 26 May 2013 08:38:50 +0200 Received: from ndokos by pool-108-7-96-134.bstnma.fios.verizon.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 26 May 2013 08:38:50 +0200 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Nicolas Goaziou writes: > Nick Dokos writes: > >> Nicolas Goaziou 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? > 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). The reason I was using dvipng is that the dvipng preview method predated the imagemagick method so that's where I started and that's where I stayed, but it was trivial to switch to imagemagick for experimentation and I may stick with it in the end. And the only reason I can see for keeping both is so that nobody's workflow gets broken. > 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. I switched to texi2dvi a long time ago, even patching it when its infamous bug was still around. By this time, it might even be possible to actually make it the default (although Windows might present problems again). But given the history, it doesn't give one the warm fuzzies either. > 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. > 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. >> 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? > 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. 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. -- Nick