# Orgmode export: how to prevent a new line for comment lines

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):

\begin{document}
\tableofcontents

First sentence.

Last sentence.
\end{document}


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
(loop for comment in (reverse (org-element-map (org-element-parse-buffer)
'comment 'identity))
do
(setf (buffer-substring (org-element-property :begin comment)
(org-element-property :end comment))
"")))

(switch-to-buffer (org-latex-export-as-latex)))
#+END_SRC


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)
(erase-buffer)
(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.