Re: [O] [RFC] [PATCH] conditional use of latex packages
Hi Nicolas, Thank you for your comments on this patch. I appreciate your concerns about the ordering of packages – this was something I had not considered fully. I have reworked the implementation; I think it is now simpler and more robust. Instead of a new customization variable, I’ve added a field to ‘org-latex-(default-)packages-alist’, which indicates whether a package is to be loaded always, or only if needed. This is very similar to the mechanism that already exists to load only a subset of packages when compiling latex snippets. This flag is initially set to nil for all packages, which loads them unconditionally – that is, the default behavior is unchanged. Users can set this flag to t for packages for which they are sure that optional loading is appropriate. 2013ko otsailak 21an, Nicolas Goaziou-ek idatzi zuen: [...] > > My point was that they provide distinct features, so they should be > included in different sets. But that's your call, really. You are right about this – I could not see the forest for the trees. I’ll send the tikz images patch separately. >> 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'. What I meant was that the code for the latex exporter specifically mentions those packages. There is a very small set of latex packages that are “blessed” in that way. > 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'). Hopefully the new version of the patch addresses this concern. > > 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. Well, the LaTeX file which is the output of org’s exporter is always available for debugging if something goes wrong. The new patch explicitly indicates when a package is omitted because org thinks it is unnecessary, so hopefully it will be very obvious when something goes wrong. (Also, org omitting a package will only happen if the user requests it explicitly.) The patch should appear as a reply to this email. -- Aaron Ecay
Re: [O] [RFC] [PATCH] conditional use of latex packages
Aaron Ecay 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
Re: [O] [RFC] [PATCH] conditional use of latex packages
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
Re: [O] [RFC] [PATCH] conditional use of latex packages
Hello, Aaron Ecay writes: > The current way that org handles LaTeX packages for export isn’t > optimal. The org-latex-(default-)packages-alist variables define a set > of packages that are loaded always. If a user wants to use advanced > functionality (booktabs for nicer table export, listings or minted for > nicer source code), s/he has to add the packages to these variables > manually.And a package like longtables is imported into every > document, slowing down compilation even when it is not used. I think you are misusing latex back-end configuration. Obviously, if you need a package in every document you write, it should go into `org-latex-packages-alist'. 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. > The attached patches (specifically 1, 2, and 5) introduce a mechanism to > load certain packages only when needed. It is possible to customize > these packages by specifying options to be passed to their \usepackage > (only inserted if needed to properly export the document), as well as > arbitrary code to place in the document’s preamble if the package is > used. 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. Notwithstanding conditional package insertion, `org-latex-classes' provides the same set of features. > The other patches in the series (3, 4) fix the latex exporter’s handling > of tikz image files, as generated by R’s tikzDevice function. > Currently, a link to the file containing the graphics code is inserted. > The proper behavior is to \input the file; the source code therein is > compiled into a graph by LaTeX as it compiles the document. (Tikz is a > very expensive latex package to load; the ability to load tikz only when > necessary motivated the optional packages mechanism.) I don't mind that change. Would you mind providing it as a separate set of patches? Anyway, nothing can be applied before FSF registration is complete. > I think these patches need more testing, but I wanted to send them along > for feedback. If it is not desired to change the status quo > wrt. packages like booktabs and minted (must be manually added), and > wrapfig and longtable (will always be used even if not needed), it would > be possible to accept only patches 1, 3, and 4. (But obviously I think > the other patches are a marked improvement.) I don't mind removing "longtable" from `org-latex-default-packages-alist'. I think there's no reason for it to be there. Regards, -- Nicolas Goaziou
Re: [O] [RFC] [PATCH] conditional use of latex packages
Hello Aaron, On Wed, Feb 20, 2013 at 11:02:21PM -0500, Aaron Ecay wrote: > Hello, > > The current way that org handles LaTeX packages for export isn’t > optimal. The org-latex-(default-)packages-alist variables define a set > of packages that are loaded always. If a user wants to use advanced > functionality (booktabs for nicer table export, listings or minted for > nicer source code), s/he has to add the packages to these variables > manually. And a package like longtables is imported into every > document, slowing down compilation even when it is not used. [...] I fully sympathise with your intentions and will test the patches at the earliest when I have some time (probably tomorrow). Cheers, -- Suvayu Open source is the future. It sets us free.