Re: Should comments break paragraphs?

[Eric Schulte <schulte.eric@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1435 bytes --]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Hello,
>
> Christian Wittern <cwittern@gmail.com> writes:
>
>> Hmm.  In my book, the concept of comments implies that they should be
>> able to appear on any line in the text, without altering the meaning
>> of the context it appears in.  So to me, it would seem necessary to
>> treat comments as special, different from other elements.
>
> I don't think comments make much sense anywhere in Org (e.g., in an
> example block or in a source block). Also Org has no inline comment
> syntax (and I don't think it needs one: it is no programming language).
> So comments do not really fit in paragraphs.
>

When Org-mode is used as a document preparation language inline comments
are very useful.  The use case being notes on the surrounding material
which are not to be published.  Both HTML and LaTeX support comments and
at least in LaTeX they are extensively used (in my experience) and can
be very helpful.

>
> Last, but not least, it is also easier to parse it that way.
>

Stripping lines starting with "^ *#[^+]" is a trivial pre-processing
step, and would support the traditional Org-mode comments which (as I
recall) could previously appear mid paragraph without causing problems.

>
> Now, if you want to improve comments anyway, you can always provide
> patches. There's some non-trivial work involved, though.
>

The attached patch worked on some small example files for me.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-support-inline-comments-w-o-breaking-paragraphs.patch --]
[-- Type: text/x-patch, Size: 1661 bytes --]

From ce4c30ebe56d4cd66810bca48824d8841e7b130d Mon Sep 17 00:00:00 2001
From: Eric Schulte <schulte.eric@gmail.com>
Date: Tue, 16 Jul 2013 09:44:59 -0600
Subject: [PATCH] support inline comments w/o breaking paragraphs

* lisp/org-element.el (org-element-parse-buffer): Strip inline comments
  as a pre-processing step before exporting.
---
 lisp/org-element.el | 20 +++++++++++++-------
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/lisp/org-element.el b/lisp/org-element.el
index 8d64657..d69d9ba 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -4092,13 +4092,19 @@ or objects within the parse tree.
 
 This function assumes that current major mode is `org-mode'."
   (save-excursion
-    (goto-char (point-min))
-    (org-skip-whitespace)
-    (org-element--parse-elements
-     (point-at-bol) (point-max)
-     ;; Start in `first-section' mode so text before the first
-     ;; headline belongs to a section.
-     'first-section nil granularity visible-only (list 'org-data nil))))
+    (let ((save (buffer-string)))
+      (unwind-protect
+	  (progn
+	    (goto-char (point-min))
+	    (delete-matching-lines "^ *# .[^\n]*\n")
+	    (org-skip-whitespace)
+	    (org-element--parse-elements
+	     (point-at-bol) (point-max)
+	     ;; Start in `first-section' mode so text before the first
+	     ;; headline belongs to a section.
+	     'first-section nil granularity visible-only (list 'org-data nil)))
+	(delete-region (point-min) (point-max))
+	(insert save)))))
 
 (defun org-element-parse-secondary-string (string restriction &optional parent)
   "Recursively parse objects in STRING and return structure.
-- 
1.8.3.2


[-- Attachment #3: Type: text/plain, Size: 71 bytes --]


Cheers,

>
>
> Regards,

-- 
Eric Schulte
http://cs.unm.edu/~eschulte