Ken Mankoff | 28 Jul 04:08 2014

Re: Include lengthy LaTeX in export preamble

Hi Jacob,

#+LATEX_HEADER: does work on export (when else would it work?)

I think I recall a space between the ":" and the LaTeX command is
needed. Do you have one?

For more ideas on how to have lengthy custom headers, see thread here:
and links therein. There are three general approaches:

1) Make a custom class file and include that, either in your init file
or in the Org file.

2) From Aaron Ecay, put your header in a #+BEGIN_SRC latex section, and
then run a bit of lisp to export that section, and then include the
exported file in a #+LATEX_HEADER: \include{preamble}. This is the
approach I use.

| #+begin_src emacs-lisp
|   (org-babel-goto-named-src-block "preamble")
|   (org-babel-tangle)
| #+end_src
| #+name: preamble
| #+begin_src latex :tangle preamble.tex
|   % code goes here
| #+end_src
(Continue reading)

Steven Arntson | 28 Jul 03:21 2014

beginner agenda question

Simple question, I think, but it has me stumped. I'm wondering what
variable controls the org-agenda function that gives you upcoming
events, a la:

  todo:       In   2 d.:  TODO Friend's Birthday
  todo:       In   4 d.:  TODO Rehearsal
  todo:       In   4 d.:  TODO Happy Hour
  todo:       In   9 d.:  TODO Some other thing

I'd like to get rid of all of that, actually. For me, it clutters things
up too much.

Thank you!

Jacob Gerlach | 28 Jul 03:00 2014

Include lengthy LaTeX in export preamble

I have a lengthy command customization that I want to include in LaTeX export. Since it must appear in the preamble, 

didn't work. I had to prepend 
to each line in order to achieve my result.

I found C-h v org-format-latex-header RET:

"The document header used for processing LaTeX fragments..."

But it seems that when the docstring says "fragments," it is not referring to exporting.

Are there any customizations to do the same during export?

Leu Zhe | 28 Jul 02:11 2014

·Open footnote link definition from reference directly

Hi orgers,

I wrote a little snippet below to open footnote link definition directly with a single call.
I think it will be very useful when you have a lot of link footnote definitions in you documents.
Since I am a newbie to lisp, any advice of improvement will be really appreciate.

(defun open-footnote-link ()
  "Open footnote link directly without going to definition"
    (if (org-footnote-at-reference-p)
    (message "Must be in footnotes with link definition"))))

(global-set-key (kbd "C-c C-x l") 'open-footnote-link)

Phil Chrapka | 27 Jul 23:02 2014

Clear non-repeated scheduled time when deadline is repeated

I'm having the exact same issue as this question on stackoverflow and I've copied it below.

The solution provided to the question modifies the source, which I'd like to avoid if possible. Is there a better way of doing this like by setting a variable or a hook? Or does anyone have better ideas about this type of workflow?

I use org-mode to manage some deadlines for repeated tasks. For example, I may have something like the following:
* TODO My Weekly Task
  DEADLINE <2013-08-10 Sat +1w>
If I mark the task as DONE, then the deadline automatically increments to the next week as expected. However, I also like to use the SCHEDULED time to indicate when during the week I would like to actually do that task, for example:
* TODO My Weekly Task
  DEADLINE <2013-08-10 Sat +1w> SCHEDULED: <2013-08-08 Thu>
This makes the task show up in the agenda for today (Thursday). However when I mark the task DONE, I end up with the following:
* TODO My Weekly Task
  DEADLINE <2013-08-17 Sat +1w> SCHEDULED: <2013-08-08 Thu>
...and the task still appears in the agenda view for today, even though it has been completed.
Is it possible, for tasks that have a repeated DEADLINE, to get Org-Mode to clear the non-repeated SCHEDULED date?

--- a/lisp/org.el
+++ b/lisp/org.el
<at> <at> -12835,7 +12835,8 <at> <at> This function is run automatically after each state change to a DONE state."
    (setq type (if (match-end 1) org-scheduled-string
             (if (match-end 3) org-deadline-string "Plain:"))
          ts (match-string (if (match-end 2) 2 (if (match-end 4) 4 0))))
-   (when (string-match "\\([.+]\\)?\\(\\+[0-9]+\\)\\([hdwmy]\\)" ts)
+   (if (not (string-match "\\([.+]\\)?\\(\\+[0-9]+\\)\\([hdwmy]\\)" ts))
+       (org-remove-timestamp-with-keyword org-scheduled-string)
      (setq n (string-to-number (match-string 2 ts))
        what (match-string 3 ts))
      (if (equal what "w") (setq n (* n 7) what "d")) 

David Arroyo Menendez | 27 Jul 21:26 2014



I've some functions in worg/code/elisp/davidam.el, that could be
interesting contribute to org-mode (I use davidam-org-src every
day). The functions are:

+ davidam-org-envolve-src(msg)
+ davidam-org-src(msg)
+ davidam-org-envolve-check-list()
+ davidam-org-envolve-numbered-list()

My doubt is if is better work more to create a new file, or if someone
thinks that can be integrated in some existing org file.


Sebastian Fischmeister | 27 Jul 18:40 2014

Export agenda to HTML with links to body contents


I upload my agenda on a website, so I can access it from multiple
devices. This works nicely with the following in a cron job:

emacs --batch -l ~/.emacs.d/init.el -eval '(org-batch-store-agenda-views)' -kill

The only thing I'm missing is links to the body of the item. Does Org
currently support anything in the HTML export that could enable showing
the content on a click? For example:

** Item 1
   This text here would be visible when you click on "Item 1" in the
   HTML-exported document.

The link on "Item 1" could lead to a separate page or it could use some
fancy CSS/Javascript.

Any ideas?


Nicolas Goaziou | 27 Jul 14:37 2014

[ANN] Merge export-block type within special-block


Export blocks are blocks dedicated to export back-ends, e.g.,
"#+BEGIN_LATEX". The way they are currently parsed is flawed.

Export blocks are back-end dependent. At the moment, back-ends register
their own export block in a variable, `org-element-block-name-alist', so
the parser can know if it needs to parse an export block or not. As
a consequence, the same block can be parsed differently if a given
export back-end is loaded or not. E.g.,


will be parsed as a `special-block' if "ox-html.el" is not loaded, or an
`export-block' otherwise. This is slightly... ugly. And it gets worse if
we include the cache, which will not update the block if it is not

I just committed a set of patches that solve the problem: `export-block'
elements do not exist anymore. Instead, such blocks are now parsed as
`special-block', always. This does not depend on the libraries loaded so

Of course, special blocks are not treated exactly as export blocks. The
latter's contents are included as-is in the output whereas the former's
are interpreted. Therefore, special blocks now include another
property, :raw-value, which stores the pristine initial contents of the
block, and "ox.el" provides a new function,
`org-export-raw-special-block-p', which tells the difference between
a former export block and a special block. This makes sense since an
"export-block" is clearly, and only, an export concept. This is not
related to Org syntax.

This is more simple to handle than it sounds, and can be described with
two steps:

  1. `export-block' elements, translators and filters are now ignored.
     These can be removed from export back-ends (unless you want to
     preserve compatibility with Org 8.2, in which case leaving them
     will not hurt: they will be used in Org 8.2 and ignored in Org

  2. Translators for special blocks, e.g. `org-BACKEND-special-block'
     need to be updated and check first if current block is a raw
     special block or not. The following template is a suggestion.

     #+BEGIN_SRC emacs-lisp
     (defun org-latex-special-block (special-block contents info)
       (if (org-export-raw-special-block-p special-block info)
           (org-element-property :raw-value special-block)
         ;; Usual handling for special blocks goes here.

     Note that if BACKEND is a derived back-end and doesn't implement
     its own special block translator already, there is nothing to
     change. The parent back-end will take care of such blocks.

     All back-ends in core and in contrib have been updated this way

I included `org-export-raw-special-block-p' in Org 8.2, as
a forward-compatibility measure, so back-end maintainers do not have to
do the `fboundp' dance.

BTW, for those in the back of the room: I didn't remove
"#+BEGIN_LATEX"-like constructs.



Nicolas Goaziou                                                0x80A93738

Thorsten Jolitz | 27 Jul 01:51 2014

[WORG] Link in 'org-latex-export.html' does not work.

Hi List, 



line 542 

the link to 'org-exp-blocks' does not work:

| Location:             
| Cannot retrieve URL:
| 404 Not Found

trailing .html is missing, this works:




Jude DaShiell | 27 Jul 01:10 2014

basic checklist getting more complex

I put together a basic checklist for a familymember and was asked to 
categorize all items in the list and then to priortize all items in each 
category.  I've never done either of these things to a basic checklist so 
figured to ask what's the best way to do this so each item in the list 
once categorized and prioritized doesn't loose its category or priority if 
the checklist items somehow get out of order for some reason.
I could use single level headlines for categories but if the document 
looses any one of those headlines, the category structure is degraded.

If a cannonical emacs-orgmode procedure exists for doing these things and 
it's already documented I could use an url pointing to the material if 
anyone knows of one.

jude <jdashiel <at>>

Samuel Wales | 26 Jul 23:51 2014

Re: c-c ' in babel source blocks strips final newline or adds blank line upon returning, but never neither

hi thorsten,

i think there are several misunderstanding here.

first, i am not talking about outorg at all.  i am talking about babel
source code blocks.  i have changed the subject header to make that
more obvious.  outorg is not relevant to this thread, as far as i can

second, emacs behavior is not built in.  it depends on
require-final-newline.  if babel would respect require-final-newline,
i would be happy.  however, it does not.  so it is not an emacs issue
in this respect.

third, before posting the original post, i fully tested both the
variable that you suggested and require-final-newline.  the value of
the former determines which bug occurs.

i hope that's enough to get us all on the same page.  i have very
severe rsi so i limit typing to less than 4 minutes at a time.  i
won't be able to reply for some time.