emacs-orgmode
[Top][All Lists]
Advanced

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

Re: [O] [export] Should sidewaystable option automatically add rotating


From: Rasmus
Subject: Re: [O] [export] Should sidewaystable option automatically add rotating package?
Date: Thu, 12 Sep 2013 20:33:02 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Nicolas Goaziou <address@hidden> writes:

> Hello,
>
> Rasmus <address@hidden> writes:
>
>> So the question is should it be a default package?
>>
>> I think not.  E.g. tabu isn't loaded.  Amsmath isn't loaded if you
>> generate a matrix.
>
> I think the "tabu" case (and longtable...) is different from "rotating".
>
> No feature in Org requires "tabu" or "longtable" unless user explicitly
> writes "tabu" or "longtable" somewhere in the buffer (i.e.
> in :environment attribute).
>
> On the other hand, "rotating" or "wrapfig" may be needed without the
> user knowing about it (e.g. when setting :float or :wrap attributes).
>
> Therefore, I think "wrapfig" and "rotating" belong to the same boat.
> Either we require them both in default packages, or we do not require
> any and add a footnote about it in the manual. I have no preference.
>
> On the same line, we could remove "longtable" from
> `org-latex-default-packages-alist', if only to spare a few kittens.
>
> WDYT?

It's tough.  I've /never/ used neither wrapfig nor longtable.  From a
totally subjective point-of-view I'd certainly want to remove it!
However, I wonder if this is the 'nicest' thing to do.  Not everyone
cares about LaTeX and not everyone cares to look into LaTeX details.

Three possibilities are

  - Just Workᵀᴹ ::  Include a lot of stuff in
      `org-latex-default-packages-alist'.  Self-proclaimed 'power
      users' can cut it down themselves in their config.  It could
      slow down compilation, especially if policy is too lenient.
      (E.g. to support tikz files you need to load TiKZ; To
      support #+LANGUAGE you need to load babel).  Perhaps we could
      add an optional variable org-latex-load-all-relevant-packages
      that loads all known packages that Org might depend on (assuming
      they are all compatible).  People with i7 processors can then
      turn it on and we could include only basic package in the
      default package alist.

  - RTM :: Be better at documenting when a feature requires an
           additional package.  This is probably my preferred
           solution.

           I think Org can mostly guess when a LaTeX export failed.
           If so, perhaps we could be give informative hints when
           something fails.  E.g. if rotation is required and
           something fails, tell the user that the rotation package is
           needed.  I have no idea how much work this would be.

  - Do nothing :: People who use the LaTeX exporter should be
                  proficient enough with LaTeX and Org to solve their
                  own problems.

On Eric's original idea about auto-including packages: I don't like.
I want to like it, but it's just too fragile.  Some things depend on
being loaded in the correct order (e.g. hyperref needs to be towards
the end).  Since people can load arbitrary code using #+LATEX_HEADER:
\input{·} it's bound to break!

–Rasmus

-- 
The Kids call him Billy the Saint



reply via email to

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