emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Carsten Dominik <carsten.dominik@gmail.com>
To: "Sébastien Vauban" <wxhgmqzgwmuf@spammotel.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Re: [PATCH] Compiling multiple times the LaTeX output
Date: Tue, 5 Oct 2010 16:17:35 +0200	[thread overview]
Message-ID: <FC5DBC68-FE47-49F4-A19A-0F35254A799B@gmail.com> (raw)
In-Reply-To: <87sk0kyfgw.fsf@mundaneum.com>


On Oct 5, 2010, at 2:46 PM, Sébastien Vauban wrote:

> Hi Carsten,
>
> Carsten Dominik wrote:
>> Thanks for the patch! I would certainly have a better way to  
>> process these
>> files.

I would certainly *like very much to have your* better way to process  
it.

Sorry about that confusing sentence...

>
> Could you make your latest sentence more explicit?
>
>
>> 1. Can we run bibtex only if we have an indication that it might be  
>> needed?
>>   Maybe by looking at the output of the first LaTeX run? Hmm, maybe  
>> this
>>   would not work if only the bibtex database file was changed.
>
> I guess things in that direction are entirely possible. I don't use  
> bibtex
> yet, but will have a look at a better integration.
>
>
>> 2. The contrill structures you are using, are they standard shell  
>> or is bash
>>   needed for this?
>
> Good question!  Yes, I implicitly wrote in bash. That won't work for  
> sure in
> Windows...
>
> But, then, how do we do for writing such shells in Emacs?  Go to  
> Emacs's
> builtin shell?  I have no experience with it, but I can have a look,  
> except:
> how would we be sure that the preferred shell of the user is that one?

I think the safe way would be to capture output of the run to an Emacs  
buffer and study it there.  this is what AUCTeX is doing, I think.

Anyway, I think your new way is already better than the old one.

Cheers.

- Carsten

>
>
>> 3. Maybe we can extract a useful error message if the last PDFLaTeX  
>> run
>>   still contains problems? Maybe even load the log file in this case?
>
> For sure, such behaviors would be a great, in case of failures.
>
> Best regards,
>  Seb
>
>>> Here is my (much) better proposition:
>>>
>>> --8<---------------cut here---------------start------------->8---
>>> diff --git a/lisp/org-latex.el b/lisp/org-latex.el
>>> index 9a62457..0a2c5fe 100644
>>> --- a/lisp/org-latex.el
>>> +++ b/lisp/org-latex.el
>>> @@ -455,25 +455,35 @@ allowed.  The default we use here  
>>> encompasses both."
>>>  :group 'org-export-latex
>>>  :group 'org-export)
>>>
>>> +(defcustom org-latex-pdf-max-runs 3
>>> +  "Maximum number of times PDFLaTeX is run after BibTeX."
>>> +  :group 'org-export-pdf
>>> +  :type 'int)
>>> +
>>> (defcustom org-latex-to-pdf-process
>>> -  '("pdflatex -interaction nonstopmode -output-directory %o %f"
>>> -    "pdflatex -interaction nonstopmode -output-directory %o %f")
>>> +  `("pdflatex -interaction nonstopmode -output-directory %o %f"
>>> +    "bibtex %b"
>>> +    ,(concat "let COUNTER=0; while (grep -e \"Rerun .* cross-
>>> references\" %b.log > /dev/null); do if [ $COUNTER -eq "
>>> +             (int-to-string org-latex-pdf-max-runs)
>>> +             " ]; then break; fi; pdflatex -interaction nonstopmode
>>> -output-directory %o %f; let COUNTER=COUNTER+1; done"))
>>>  "Commands to process a LaTeX file to a PDF file.
>>> This is a list of strings, each of them will be given to the shell
>>> as a command.  %f in the command will be replaced by the full file  
>>> name, %b
>>> by the file base name (i.e. without extension) and %o by the base  
>>> directory
>>> of the file.
>>> The reason why this is a list is that it usually takes several  
>>> runs of
>>> -pdflatex, maybe mixed with a call to bibtex.  Org does not have a  
>>> clever
>>> -mechanism to detect which of these commands have to be run to get  
>>> to a
>>> stable
>>> -result, and it also does not do any error checking.
>>> +pdflatex, mixed with a call to bibtex.  Org does now have a clever
>>> mechanism
>>> +to detect how many times the document has to be compiled to get  
>>> to a stable
>>> +result for the cross-references.  Moreover, the number of  
>>> compilations
>>> after
>>> +bibtex is limited to 3 by default (see `org-latex-pdf-max-runs'  
>>> for more).
>>> +Though, it does not do any error checking.
>>>
>>> Alternatively, this may be a Lisp function that does the  
>>> processing, so you
>>> could use this to apply the machinery of AUCTeX or the Emacs LaTeX  
>>> mode.
>>> This function should accept the file name as its single argument."
>>>  :group 'org-export-pdf
>>>  :type '(choice (repeat :tag "Shell command sequence"
>>> -		  (string :tag "Shell command"))
>>> +			 (string :tag "Shell command"))
>>> 		 (function)))
>>>
>>> (defcustom org-export-pdf-logfiles
>>> --8<---------------cut here---------------end--------------->8---
>>>
>>> Enhancements:
>>>
>>> - variable to limit the number of PDFLaTeX runs (3, by default)
>>>
>>> Though, the way it is evaluated, you need to set it before calling
>>> org-latex
>>> (before defining org-latex-to-pdf-process). Not a problem, IMHO.  
>>> Maybe
>>> there
>>> are better ways, though?
>>>
>>> - real standard sequence to compile the doc:
>>>
>>> + one call to PDFLaTeX
>>> + one call to BibTeX
>>> + as many calls as needed to PDFLaTeX (max 3)
>
> -- 
> Sébastien Vauban
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode

- Carsten

  reply	other threads:[~2010-10-05 14:20 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-29 14:25 Compiling multiple times the LaTeX output Sébastien Vauban
2010-09-29 15:17 ` Noorul Islam K M
2010-09-30 13:27   ` [PATCH] " Sébastien Vauban
2010-09-30 15:39     ` Nick Dokos
2010-09-30 16:55       ` Sébastien Vauban
2010-10-01 15:32         ` Thomas S. Dye
2010-10-01 21:17           ` Sébastien Vauban
2010-10-04  7:41             ` Carsten Dominik
2010-10-04 10:36               ` Scot Becker
2010-10-05 12:46               ` Sébastien Vauban
2010-10-05 14:17                 ` Carsten Dominik [this message]
2010-10-05 14:30                 ` Matthew Leifer
2010-10-05 15:02                   ` Indraneel Majumdar
2010-10-05 16:26                   ` Carsten Dominik
2010-10-05 18:55                     ` Achim Gratz
2010-10-05 21:12                       ` Carsten Dominik
2010-10-06  8:21                     ` Sébastien Vauban
2010-10-05 18:24                   ` Achim Gratz
2010-10-01 16:12         ` Nick Dokos
2010-10-06  9:36           ` Bruno Tavernier
2010-10-06 20:39             ` Matthew Leifer
2010-10-07  2:09               ` Bruno Tavernier
2010-10-13  7:49               ` Olivier Schwander
2010-10-13 12:34                 ` Carsten Dominik
2010-10-06 21:54             ` Scot Becker

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=FC5DBC68-FE47-49F4-A19A-0F35254A799B@gmail.com \
    --to=carsten.dominik@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=wxhgmqzgwmuf@spammotel.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).