From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Elston Subject: Re: Request for feedback about LaTeX setup changes Date: Mon, 05 Apr 2010 11:28:56 -0700 Message-ID: <4BBA2BE8.1080005@comcast.net> References: <7A9D7D79-E29E-476F-9EEC-1778DADB404F@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nyr2t-0000US-Ut for emacs-orgmode@gnu.org; Mon, 05 Apr 2010 14:29:12 -0400 Received: from [140.186.70.92] (port=34112 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nyr2r-0000Tr-Kr for emacs-orgmode@gnu.org; Mon, 05 Apr 2010 14:29:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nyr2p-0008EI-HG for emacs-orgmode@gnu.org; Mon, 05 Apr 2010 14:29:09 -0400 Received: from qmta07.westchester.pa.mail.comcast.net ([76.96.62.64]:33110) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nyr2o-0008EA-SO for emacs-orgmode@gnu.org; Mon, 05 Apr 2010 14:29:07 -0400 In-Reply-To: <7A9D7D79-E29E-476F-9EEC-1778DADB404F@gmail.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Carsten, I, for one, like this writeup. It is very clear concerning the ins and outs of the new setup. Of course, I paid attention to all the other discussion on this topic so I may be somewhat biased. It only *sounds* complicated when you see it all laid out like you have it below. It breaks down to some simple mechanisms as you have shown. Mark On 4/5/2010 6:13 AM, Carsten Dominik wrote: > Dear all, > > I need some feedback. > > Here is new new section from the list of changes, about the LaTeX setup. > I would like to hear honest answers if I have gone completely crazy, of > if this actually makes any sense. > > Thanks. > > - Carsten > -------------------------------------------------------------------------- > Changes to the intended use of =org-export-latex-classes= > ========================================================= > > So far this variable has been used to specify the complete header > of the LaTeX document, including all the =\usepackage= calls > necessary for the document. This setup makes it difficult to > maintain the list of packages that Org itself would like to call, > for example for the special symbol support it needs. Each time I > have to add a package, I have to ask people to revise the > configuration of this variable. In this release, I have tried to > fix this. > > First of all, you can *opt out of this change* in the following > way: You can say: /I want to have full control over headers, and > I will take responsibility to include the packages Org needs/. > If that is what you want, add this to your configuration and skip > the rest of this section (except maybe for the description of the > =[EXTRA]= place holder): > > > (setq org-export-latex-default-packages-alist nil > org-export-latex-packages-alist nil) > > /Continue to read here if you want to go along with the modified > setup./ > > There are now two variables that should be used to list the LaTeX > packages that need to be included in all classes. The header > definition in =org-export-latex-classes= should then not contain > the corresponding =\usepackage= calls (see below). > > The two new variables are: > > 1. =org-export-latex-default-packages-alist= :: This is the > variable where Org-mode itself puts the packages it needs. > Normally you should not change this variable. The only > reason to change it anyway is when one of these packages > causes a conflict with another package you want to use. > Then you can remove that packages and hope that you are not > using Org-mode functionality that needs it. > > 2. =org-export-latex-packages-alist= :: This is the variable > where you can put the packages that you'd like to use across > all classes. For example, I am putting =amsmath= and =tikz= > here, because I always want to have them. > > The sequence how these customizations will show up in the LaTeX > document are: > 1. Header from =org-export-latex-classes= > 2. =org-export-latex-default-packages-alist= > 3. =org-export-latex-packages-alist= > 4. Buffer-specific things set with =#+LaTeX_HEADER:= > > If you want more control about which segment is placed where, or > if you want, for a specific class, have full control over the > header and exclude some of the automatic building blocks, you can > put the following macro-like place holders into the header: > > > [DEFAULT-PACKAGES] \usepackage statements for default packages > [NO-DEFAULT-PACKAGES] do not include any of the default packages > [PACKAGES] \usepackage statements for packages > [NO-PACKAGES] do not include the packages > [EXTRA] the stuff from #+LaTeX_HEADER > [NO-EXTRA] do not include #+LaTeX_HEADER stuff > > If you have currently customized =org-export-latex-classes=, you > should revise that customization and remove any package calls that > are covered by =org-export-latex-default-packages-alist=. This > applies to the following packages: > > - inputenc > - fontenc > - graphicx > - longtable > - float > - wrapfig > - soul > - t1enc > - textcomp > - marvosym > - wasysym > - latexsym > - amssymb > - hyperref > > If one of these packages creates a conflict with another package > you are using, you can remove it from > =org-export-latex-default-packages-alist=. But then you risk > that some of the advertised export features of Org will not work > properly. > > You can also consider moving packages that you use in all classes > to =org-export-latex-packages-alist=. If necessary, put the > place holders so that the packages get loaded in the right > sequence. As said above, for backward compatibility, if you omit > the place holders, all the variables will dump their content at > the end of the header. > > Damn, this has become more complex than I wanted it to be. I > hope that in practice, this will not be complicated at all. >