emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Carsten Dominik <carsten.dominik@gmail.com>
To: "Thomas S. Dye" <tsd@tsdye.com>
Cc: nicholas.dokos@hp.com, emacs-orgmode@gnu.org
Subject: Re: Karl Berry: Re: Nick Dokos: texi2dvi egrep regexp
Date: Sun, 10 Oct 2010 09:05:56 +0200	[thread overview]
Message-ID: <B71CE7D2-BD66-428F-A709-A9CACBF1D8FA@gmail.com> (raw)
In-Reply-To: <548BC6EA-FAFB-42F5-AFE3-EC45DAA8FA48@tsdye.com>


On Oct 9, 2010, at 7:25 PM, Thomas S. Dye wrote:

> On Oct 9, 2010, at 6:42 AM, Nick Dokos wrote:
>
>> Carsten Dominik <carsten.dominik@gmail.com> wrote:
>>
>>
>>> I am looking for a way out which will allow pdf compilation of Org
>>> work out of the box, and still allow texi2dvi to be used where  
>>> possible.
>>>
>>> I have so far come up with two possible work-arounds and would
>>> like to hear if one of them makes sense:
>>>
>>> 1.  I could set the environment variable LC_ALL
>>>   for the duration of the texi2dvi command to some value
>>>   like C?  That should fix the egrep call, but could
>>>   it have adverse effects on the pdflatex and bibtex runs or
>>>   any other stuff used in texi2dvi?
>>>
>>
>> Yes, at least theoretically. I don't think anybody has gone down
>> the path of investigating these effects.
>>
>>> 2. On startup, I could use
>>>
>>>  (if (= 0 (shell-command "echo foo | egrep \"[A-z]\""))
>>>           ....
>>>
>>>
>>>  to check if there is a problem and in this case go for
>>>  manual pdflatex runs rather than using texi2dvi.  THis might work,
>>>  but it would be a bit unpredictable what ends up being used,
>>>  and with no setup in Org you could get different sets of commands
>>>  on different machines.
>>>
>>
>> The trouble with this is that you are checking on egrep which will  
>> give
>> you a positive for egrep versions >= 2.6.x, but the fix to texi2dvi  
>> might
>> have made that irrelevant. How about
>>
>>    try
>>       texi2dvi
>>    except
>>       do Seb's thrice-repeated pdflatex (or whatever) call
>>
>> After everybody has updated to the latest texinfo, the exception code
>> can be taken out.
>>
>> Alternatively, the texi2dvi method can be reverted: it was an idea  
>> that
>> was worth trying, but it has caused more harm than good at this point
>> - maybe it can be revisited in six months.
>>
>>> Any ather ideas?  Comments?
>>>
>>
>
> Perhaps org-latex-to-pdf-process should just run pdflatex twice (or  
> three times) so that it most likely will work out of the box.  IIUC,  
> the user can set this variable to something else.

I think this is the best idea.  I am going to set the default to 3  
runs of pdflatex and provide a customization option to use texi2dvi.
FOr now, I think the danger of this going wrong for unsuspecting users  
is worse than the advantage of using texi2dvi.

So if texi2dvi works on your system, just configure org-latex-to-pdf- 
process.  If you use the customize interface to do the customization,  
one of the options will be texi2dvi.

>  Some ready-to-use alternatives on Worg might be useful.  There, the  
> pitfalls of using texi2dvi could be explained and those with systems  
> where it works could find a recipe and make use of it.  The use of  
> other latex make files might be illustrated there as well.

Good idea.

- Carsten

  reply	other threads:[~2010-10-10  7:06 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-08 18:51 Karl Berry: Re: Nick Dokos: texi2dvi egrep regexp Nick Dokos
2010-10-09  4:06 ` suvayu ali
2010-10-09 10:27   ` Eric S Fraga
2010-10-09 15:27     ` Carsten Dominik
2010-10-09 16:28       ` Matthew Leifer
2010-10-09 16:42       ` Nick Dokos
2010-10-09 17:25         ` Thomas S. Dye
2010-10-10  7:05           ` Carsten Dominik [this message]
2010-10-10 16:37             ` Thomas S. Dye
2010-10-10 18:04         ` Eric S Fraga
2010-10-09 16:59       ` Achim Gratz

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=B71CE7D2-BD66-428F-A709-A9CACBF1D8FA@gmail.com \
    --to=carsten.dominik@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=nicholas.dokos@hp.com \
    --cc=tsd@tsdye.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).