emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Nicolas Goaziou <n.goaziou@gmail.com>
To: emacs-orgmode@gnu.org
Subject: Re: [RFC] [PATCH] conditional use of latex packages
Date: Thu, 21 Feb 2013 19:39:50 +0100	[thread overview]
Message-ID: <87ppzt1pft.fsf@gmail.com> (raw)
In-Reply-To: <87r4k9shaz.fsf@gmail.com> (Aaron Ecay's message of "Thu, 21 Feb 2013 12:33:24 -0500")

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

  reply	other threads:[~2013-02-21 18:40 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-21  4:02 [RFC] [PATCH] conditional use of latex packages Aaron Ecay
2013-02-21  4:02 ` [PATCH 1/5] ox-latex: add optional-packages machinery Aaron Ecay
2013-02-21  4:02 ` [PATCH 2/5] ox-latex: convert source code and table export to use optional packages Aaron Ecay
2013-02-21  4:02 ` [PATCH 3/5] ob-R: change the file extension for tikz figures Aaron Ecay
2013-02-21  4:02 ` [PATCH 4/5] ox-latex: Treat tikz files as images Aaron Ecay
2013-02-21  4:02 ` [PATCH 5/5] ox-latex: Convert the image inclusion code to use optional packages Aaron Ecay
2013-02-21  9:51 ` [RFC] [PATCH] conditional use of latex packages Suvayu Ali
2013-02-21 15:19 ` Nicolas Goaziou
2013-02-21 17:33   ` Aaron Ecay
2013-02-21 18:39     ` Nicolas Goaziou [this message]
2013-02-24 18:47       ` Aaron Ecay
2013-02-24 18:50         ` [PATCH] ox-latex: add optional-packages machinery Aaron Ecay

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=87ppzt1pft.fsf@gmail.com \
    --to=n.goaziou@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    /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).