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

[Nicolas Goaziou <n.goaziou@gmail.com>]

Aaron Ecay <aaronecay@gmail.com> writes:

> 2013ko otsailak 21an, Nicolas Goaziou-ek idatzi zuen:

>> 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, ....

I think you're nitpicking here. Tikz may be heavy to load (I don't know,
I use asymptote) but not booktabs. There's no serious reason to have
both "article-with-tikz" and "article-with-tikz-and-booktabs".

Anyway, the point of classes is not to focus on packages only, but on
whole headers. Thus, I suggest to define classes per type of document
you create. I'm quite sure you don't need 2^n templates, n being the
number of packages you use, for that.

And if you need a specific package for a specific document, there is
LATEX HEADER keyword.

> 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.

Again, this goes against the rule "do not load a package automatically".

You're talking about optimizing LaTeX header (load a package only when
you need it). I think it's way out of Org's purpose. Is it really
important if one package is required even if it won't be used? Is it
worth adding another set of variables for that? I don't think so.

Don't get me wrong. There's nothing inherently wrong with your approach,
and it may even sound handy, but the truth is there's little benefit.

>> 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.

My point was that they provide distinct features, so they should be
included in different sets. But that's your call, really.

>> 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, 

Technically, latex exporter supports every package. That doesn't mean
all of them should by included in `org-latex-default-packages-alist'.

> which is also why wrapfig is in there, and several packages providing
> symbols for org-entities.

wrapfig and entities are a different matter. You may need them without
even realizing it. So, if they were removed from the default list, that
would cripple user's experience.

On the other hand, you need longtable package only when you explicitly
write "longtable" somewhere (e.g. in an :environment property or in
`org-latex-default-table-environment'). The user knows what he's doing
in this case.

> 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.)

I assume this would not be made to get a header of 30 lines instead of
40, but to allow an user to use features without even thinking about the
packages they require. FWIW, I think that:

  1. it's impossible to guess every package required by an user, so he
     would ultimately have to mess with even more variables to get what
     he wants (I only suggest to tweak `org-latex-class' and, optionally
     to stuff package GCD in `org-latex-packages-alist').

  2. In general, it's a bad idea to hide LaTeX internals too much as it
     can become very hard to fix a problem when things happen in your
     back.

Your work on this is interesting, but it's a can of worms, really.


Regards,

-- 
Nicolas Goaziou