3

Question: When exporting a subtree to latex and beamer with C-c C-e C-s, is it possible to use the properties drawer of a subtree to define the same properties as one would with #+LATEX_CLASS, #+LATEX_CLASS_OPTIONS, #+LATEX_HEADER?

The use case is having a single org file where you can write a file intended to be an article under one subtree, and another subtree where you write slides for a presentation.

My current setup uses #+LATEX_CLASS, #+LATEX_CLASS_OPTIONS, #+LATEX_HEADER to define the correct document class, options and packages to import when exporting with Orgmode. However, I cannot use the same values when exporting to beamer, the class is different, the options are different, and I may need to use different packages.

Thanks for helping! :D

Guilherme Salomé
  • 903
  • 8
  • 20

1 Answers1

1

I look forward to seeing other answers to this question, because I'm also looking to optimize my workflow.

In my current setup I have a single org document used as an article and as chapter of a thesis, call it research.org. The way I manage subtrees is by having :manuscript: and :thesis: tags to control export. For example, in a second file thesis.org I #+INCLUDE the document with the following derivative:

#+INCLUDE: research.org :lines "5-"
# The first five lines of research.org contain the the title, authors, some file
# specific options and a #+SETUPFILE: manuscript.setup, which includes all #LATEX_CLASS
# and #+LATEX_HEADER derivatives. I also have a #+EXCLUDE_TAGS: thesis

When I now export thesis.org, my research.org content is included and gets exported with the class defined in thesis.org. When I export research.org directly, the content is exported with the defined in research.org (or in my case #+SETUPFILE: manuscript.setup).

I imagine you could do the same by tagging subtrees that only belong to presentations and to articles, and by having a presentation.org file and a article.org file. The advantage of this approach with respect to drawers is that it gives a cleaner overview of what is going on, as tags are always visible and easy to toggle with EXCLUDE_TAGS derivatives. The disadvantage is the necessity of an extra file.

This solution is, however, quite portable in the sense that you don't need to roll any Elisp to get it working. That means your Org files should be exportable from any Emacs environment. It also gives you greater flexibility in defining your #+LATEX_HEADERs, as property drawers aren't really fit for purpose here.

Daniel
  • 3,563
  • 16
  • 41
  • Hey thanks for your comments. I'm trying to understand them better. I do not care about having extra files with latex setups, it would actually be better and make things more organized. Right now I have a `research.org` file where I write my papers, one paper per subtree, and on top of the file I have all the latex related things, like class and new command definitions. – Guilherme Salomé Aug 08 '18 at 12:38
  • Well, I think I understand your comments. To my case, I can use it to simplify my `research.org` file by having one file containing all the `common` latex definitions. Now, the question is whether I can add in the specific definitions to a subtree when exporting. Maybe it is possible to create a tag that, if found on the exporting tree, automatically includes a bunch of definitions found in some other file. – Guilherme Salomé Aug 08 '18 at 12:45
  • Check out this example repo: https://github.com/dangom/org-dual-document . It illustrates what my comment is trying to say. – Daniel Aug 08 '18 at 13:00
  • I used the option `#+SETUPFILE: "~/Dropbox/latex-common.org"` to add a bunch of definitions that I use everywhere. It gets imported and parsed when I export any subtree. The problem is that the file is imported no matter where I put the `#+SETUPFILE` option, I now need one that is evaluated only when inside a subtree being exported. – Guilherme Salomé Aug 08 '18 at 13:11
  • You should add it at the top of the file, within the region that gets excluded upon import, i.e., the :lines argument for the #+INCLUDE derivative. But in any case, in this example workflow you don't export only subtrees, you work with the whole file at all times. You use tagging and other documents for controlling the LATEX_CLASS and OPTIONS. This also makes the export file names sane and non-conflicting. – Daniel Aug 08 '18 at 13:21