emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [RFC] [PATCH] conditional use of latex packages


From: Aaron Ecay
Subject: Re: [O] [RFC] [PATCH] conditional use of latex packages
Date: Thu, 21 Feb 2013 12:33:24 -0500
User-agent: Notmuch/0.15.2+36~ge30b9e0 (http://notmuchmail.org) Emacs/24.3.50.1 (x86_64-unknown-linux-gnu)

2013ko otsailak 21an, Nicolas Goaziou-ek idatzi zuen:
> Obviously, if you need a package in every document you write, it
> should go into `org-latex-packages-alist'.

I agree with this.

> 
> If you need occasional packages, they should go into
> `org-latex-classes'. Adding a new class is cheap. For example you can
> create a class "article-with-tikz". It also allows to include
> arbitrary code within the header.

But not with this.  It leads to combinatorial explosion: you need
article-with-tikz, article-with-biblatex,
article-with-tikz-and-biblatex, article-with-tikz-and-booktabs, ....

Apart from that, I think that the latex exporter should “know” that you
need the booktabs package to export a table with the booktabs option.
So, if I send someone an org document with a booktabs table, it will
export correctly without the recipient needing to fiddle with
‘org-latex-classes’ or ‘-packages-alist’.  And the same reasoning
applies to longtables, tikz graphics, etc.  Obviously this is not true
of arbitrarily complex LaTeX constructs, but longtables, booktabs and
tikz are all supported natively by org’s syntax.

> I don't want to take that route. Bad things can happen if you load
> packages in the wrong order, or with wrong options. This is a can of
> worms. That's why no package is ever loaded automatically.

That’s true.  I don’t think that this will replace ‘org-latex-classes’ –
for certain kinds of setup it will be necessary to explicitly spell out
the latex code.  But the hope is that the kind of packages that this is
targeted at (which implement formatting options, but don’t generally
muck with lower-level things like hyperref) ordering will not be an
issue.  That might be an optimistic assumption about the state of LaTeX
packages, though...

The patch currently does not insert the optional packages in a specific
order, but it would be possible to do so (using the
‘org-latex-optional-packages-options-alist’ variable to specify the
ordering).

> 
> I don't mind that change. Would you mind providing it as a separate
> set of patches?

If the consensus is that the optional package functionality is not
wanted, I can do so.

> I don't mind removing "longtable" from
> `org-latex-default-packages-alist'. I think there's no reason for it
> to be there.

Except that the latex exporter supports it, which is also why wrapfig is
in there, and several packages providing symbols for org-entities.  I
think that a logical goal is for ‘org-latex-default-packages-alist’ to
disappear (or be shrunk to only a couple of entries), and all packages
not explicitly requested by the user (in ‘org-latex-packages-alist’ or
in an ‘org-latex-classes’ entry) to be loaded only if actually needed by
the exporter.  (Whether or not this endpoint is reached depends, as you
point out, on whether the problem of package load order can be solved in
a satisfactory way.)

-- 
Aaron Ecay



reply via email to

[Prev in Thread] Current Thread [Next in Thread]