Currently my orgmode (v8.3.4), when exporting to LaTeX (and maybe other formats but I haven't checked), generates a new line for a comment line or a block of consecutive comment lines. This is undesirable because in LaTeX, that will create a new paragraph. When I write, I often need to comment a line or two in the middle of a paragraph but don't want to split that paragraph into two. Currently, because of this behavior of orgmode, I have to move those commented lines to after the paragraph, which may be confusing when I revise the text.

Below is a minimal example. The orgmode source is:

First sentence.
# Commented sentence.
Last sentence.

which is exported to LaTeX by orgmode as (omitting the preamble):


First sentence.

Last sentence.

There is an empty line between the first and last sentences, which results in two paragraphs instead of one.

Is there any way to stop this behavior of orgmode? A comment line, or a block of comment lines, should be exported to 0 byte / character, not even a new line. This is the behavior of LaTeX when processing comments.


Try something like this. Put this code block in your document, and run it. The LaTeX will be in a buffer Org LATEX Export.

* build :noexport:
#+BEGIN_SRC emacs-lisp
(defun delete-org-comments (backend)
  (loop for comment in (reverse (org-element-map (org-element-parse-buffer)
                    'comment 'identity))
    (setf (buffer-substring (org-element-property :begin comment)
                (org-element-property :end comment))

(let ((org-export-before-processing-hook '(delete-org-comments)))
  (switch-to-buffer (org-latex-export-as-latex)))

Building on John's answer, here's an alternative function that uses org-element-extract-element and org-element-interpret-data:

(defun delete-org-comments (backend)
  (let ((tree (org-element-parse-buffer)))
    (org-element-map tree 'comment #'org-element-extract-element)
    (insert (org-element-interpret-data tree))))

The org-element API isn't particularly obvious, but it is powerful--you just have to explore it a bit on your own. :) Of course, John's is probably faster for large documents since it just modifies the buffer instead of re-interpreting the tree into a string.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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