4

While writing in org mode for export to Beamer, I've found myself creating empty headings to control structure. For example:

* 
Aliquam erat volutpat.  Nunc eleifend leo vitae magna.  In id erat non orci commodo lobortis. 
* 
Proin neque massa, cursus ut, gravida ut, lobortis eget, lacus.
** 
Sed diam.  Praesent fermentum tempor tellus.  Nullam tempus. 
** 
Mauris ac felis vel velit tristique imperdiet.  Donec at pede.
* 
Etiam vel neque nec dui dignissim bibendum.  Vivamus id enim.
** 
Phasellus neque orci, porta a, aliquet quis, semper a, massa.  Phasellus purus.  Pellentesque tristique imperdiet tortor.  Nam euismod tellus id erat.

This works fine, but if the headlines have tags, the tags are treated as the title (this occurs when adding beamer properties). For example:

* :lorem:
Aliquam erat volutpat.  Nunc eleifend leo vitae magna.  In id erat non orci commodo lobortis. 
* :ipsum:
Proin neque massa, cursus ut, gravida ut, lobortis eget, lacus.
** :dolor:
Sed diam.  Praesent fermentum tempor tellus.  Nullam tempus. 
** :sit:
Mauris ac felis vel velit tristique imperdiet.  Donec at pede.
* :amet:
Etiam vel neque nec dui dignissim bibendum.  Vivamus id enim.
** :whatever:
Phasellus neque orci, porta a, aliquet quis, semper a, massa.  Phasellus purus.  Pellentesque tristique imperdiet tortor.  Nam euismod tellus id erat.

Is this intended behavior? Is there a setting?

3

That certainly is an edge case. Some might argue that you can't have a heading without some content in the heading, but your use case seems like a reasonable use of the outline.

org-element-headline-parser isn't written to accommodate your use-case. You can change the regular expression that matches the tag portion from

(org-re "[ \t]+\\(:[[:alnum:]_@#%:]+:\\)[ \t]*$")

to

(org-re "[ \t]*\\(:[[:alnum:]_@#%:]+:\\)[ \t]*$")

(just the first quantifier is different)

I haven't done any testing on that change. Chances are it breaks something else! If it works: great :-) Otherwise you might try adding a non-breaking space in your headlines with C-q M-SPC as a workaround.

  • I think the relevant bit of code is actually at the end of that function, where it decides what the heading is. The problem is that it skips spaces and tabs and then finds the tag, which it doesn't know to ignore. Unfortunately, adding an nbsp doesn't fix the problem, because the exporter treats it as a non-empty heading and inserts the optional argument in the LaTeX. – Alex R Jun 2 '16 at 18:46
  • 1
    @Alex R My answer is based on examining the resulting org parse tree. The minor modification I made accommodates your edge case in building the parse tree correctly. If it didn't work for you post the code that did work! It's definitely possible that the export engine has duplicated logic. – ebpa Jun 2 '16 at 20:48
  • 1
    Huh. Mea culpa. I just tried out your solution (redefined the function, etc.) and it works perfectly as far as I can tell. I guess my skills at reading elisp are not as good as I thought. Out of curiosity, how did you get a look at the resulting parse tree? – Alex R Jun 3 '16 at 15:18
  • 1
    @AlexR Call the function org-element-parse-buffer It's a non-interactive function so eval (org-element-parse-buffer) in the buffer you are interested in or define your own interactive function. – ebpa Jun 6 '16 at 15:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.