[BUG] nested blocks aren't protected on export

[BUG] nested blocks aren't protected on export

[Eric Schulte]

Hi,

When exporting nested blocks, the results of the inner blocks are not
fully protected from further exportation.  For example, the following
org-mode text

--8<---------------cut here---------------start------------->8---
** protecting block bodies
#+begin_src org
  ,#+begin_src emacs-lisp
  ,  (message "something")
  ,#+end_src
#+end_src
--8<---------------cut here---------------end--------------->8---

exports to the following LaTeX

--8<---------------cut here---------------start------------->8---
\section*{protecting block bodies}
\label{sec-1}

\begin{verbatim}
  (message "something")
\end{verbatim}
--8<---------------cut here---------------end--------------->8---

in which it looks like the "#+begin_src emacs-lisp" and the "#+end_src"
lines are completely removed, and exports to the following html
(newlines added for readability)

--8<---------------cut here---------------start------------->8---
<pre class="src src-org">
<span class="org-org-meta-line">#+begin_src emacs-lisp</span>
<span class="org-org-block">  (message "something")</span>
<span class="org-org-meta-line">
</pre>
--8<---------------cut here---------------end--------------->8---

in which the #+begin_src line is in tact, but it appears everything
following the end_src line (including the </span>) is removed.

I've played around with adding 'org-protected properties during export
but to no avail.

Any suggestions are much appreciated.

Thanks -- Eric

Re: [BUG] nested blocks aren't protected on export

[Eric Schulte]

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

I've put together two patches which fix the problems I mention below.

I'd like to apply these patches, but I fear that they may cause
unanticipated export problems.  I'd be much more comfortable if someone
who knows a little more about the exporters could take a look at these.

Thanks -- Eric


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-org-exp-check-for-protection-before-removing-comment.patch --]
[-- Type: text/x-diff, Size: 1034 bytes --]

From 47fcfd522294560dbe01f00b640631964e063cf0 Mon Sep 17 00:00:00 2001
From: Eric Schulte <schulte.eric@gmail.com>
Date: Sun, 27 Jun 2010 19:35:34 -0700
Subject: [PATCH 1/2] org-exp: check for protection before removing comments

* lisp/org-exp.el (org-export-handle-comments): check for protection
  before removing comments
---
 lisp/org-exp.el |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/lisp/org-exp.el b/lisp/org-exp.el
index 704c0b7..411557a 100644
--- a/lisp/org-exp.el
+++ b/lisp/org-exp.el
@@ -1650,8 +1650,10 @@ When it is nil, all comments will be removed."
 		  (match-beginning 0) (match-end 0) '(org-protected t))
 		 (replace-match (format commentsp (match-string 2)) t t))
 	(goto-char (1+ pos))
-	(replace-match "")
-	(goto-char (max (point-min) (1- pos)))))))
+	(org-if-unprotected
+	 (replace-match "")
+	 (goto-char (max (point-min) (1- pos))))))))
+
 
 (defun org-export-mark-radio-links ()
   "Find all matches for radio targets and turn them into internal links."
-- 
1.7.0.4


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-org-latex-check-for-protection-before-wrapping-lines.patch --]
[-- Type: text/x-diff, Size: 2050 bytes --]

From d422f564163e37c51d0727e2992b24b85caf54ea Mon Sep 17 00:00:00 2001
From: Eric Schulte <schulte.eric@gmail.com>
Date: Sun, 27 Jun 2010 19:36:14 -0700
Subject: [PATCH 2/2] org-latex: check for protection before wrapping ": " lines as verbatim

* lisp/org-latex.el (org-export-latex-fixed-width): check for
  protection before wrapping ": " lines as verbatim
---
 lisp/org-latex.el |   28 ++++++++++++++--------------
 1 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/lisp/org-latex.el b/lisp/org-latex.el
index 01a4b05..94f04e6 100644
--- a/lisp/org-latex.el
+++ b/lisp/org-latex.el
@@ -1537,20 +1537,20 @@ The conversion is made depending of STRING-BEFORE and STRING-AFTER."
   "When OPT is non-nil convert fixed-width sections to LaTeX."
   (goto-char (point-min))
   (while (re-search-forward "^[ \t]*:\\([ \t]\\|$\\)" nil t)
-    (if opt
-	(progn (goto-char (match-beginning 0))
-	       (insert "\\begin{verbatim}\n")
-	       (while (looking-at "^\\([ \t]*\\):\\(\\([ \t]\\|$\\).*\\)$")
-		 (replace-match (concat (match-string 1)
-					(match-string 2)) t t)
-		 (forward-line))
-	       (insert "\\end{verbatim}\n\n"))
-      (progn (goto-char (match-beginning 0))
-	     (while (looking-at "^\\([ \t]*\\):\\(\\([ \t]\\|$\\).*\\)$")
-	       (replace-match (concat "%" (match-string 1)
-				      (match-string 2)) t t)
-	       (forward-line))))))
-
+    (org-if-unprotected
+     (if opt
+	 (progn (goto-char (match-beginning 0))
+		(insert "\\begin{verbatim}\n")
+		(while (looking-at "^\\([ \t]*\\):\\(\\([ \t]\\|$\\).*\\)$")
+		  (replace-match (concat (match-string 1)
+					 (match-string 2)) t t)
+		  (forward-line))
+		(insert "\\end{verbatim}\n\n"))
+       (progn (goto-char (match-beginning 0))
+	      (while (looking-at "^\\([ \t]*\\):\\(\\([ \t]\\|$\\).*\\)$")
+		(replace-match (concat "%" (match-string 1)
+				       (match-string 2)) t t)
+		(forward-line)))))))
 
 (defvar org-table-last-alignment) ; defined in org-table.el
 (defvar org-table-last-column-widths) ; defined in org-table.el
-- 
1.7.0.4


[-- Attachment #4: Type: text/plain, Size: 1173 bytes --]


"Eric Schulte" <schulte.eric@gmail.com> writes:

> Hi,
>
> When exporting nested blocks, the results of the inner blocks are not
> fully protected from further exportation.  For example, the following
> org-mode text
>
> ** protecting block bodies
> #+begin_src org
>   ,#+begin_src emacs-lisp
>   ,  (message "something")
>   ,#+end_src
> #+end_src
>
> exports to the following LaTeX
>
> \section*{protecting block bodies}
> \label{sec-1}
>
> \begin{verbatim}
>   (message "something")
> \end{verbatim}
>
> in which it looks like the "#+begin_src emacs-lisp" and the "#+end_src"
> lines are completely removed, and exports to the following html
> (newlines added for readability)
>
> <pre class="src src-org">
> <span class="org-org-meta-line">#+begin_src emacs-lisp</span>
> <span class="org-org-block">  (message "something")</span>
> <span class="org-org-meta-line">
> </pre>
>
> in which the #+begin_src line is in tact, but it appears everything
> following the end_src line (including the </span>) is removed.
>
> I've played around with adding 'org-protected properties during export
> but to no avail.
>
> Any suggestions are much appreciated.
>
> Thanks -- Eric

[-- Attachment #5: Type: text/plain, Size: 201 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Re: [BUG] nested blocks aren't protected on export

[Carsten Dominik]

Hi Eric,

On Jun 28, 2010, at 4:42 AM, Eric Schulte wrote:

> I've put together two patches which fix the problems I mention below.
>
> I'd like to apply these patches, but I fear that they may cause
> unanticipated export problems.  I'd be much more comfortable if  
> someone
> who knows a little more about the exporters could take a look at  
> these.
>
> Thanks -- Eric
>
> From 47fcfd522294560dbe01f00b640631964e063cf0 Mon Sep 17 00:00:00 2001
> From: Eric Schulte <schulte.eric@gmail.com>
> Date: Sun, 27 Jun 2010 19:35:34 -0700
> Subject: [PATCH 1/2] org-exp: check for protection before removing  
> comments
>
> * lisp/org-exp.el (org-export-handle-comments): check for protection
>  before removing comments
> ---
> lisp/org-exp.el |    6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/lisp/org-exp.el b/lisp/org-exp.el
> index 704c0b7..411557a 100644
> --- a/lisp/org-exp.el
> +++ b/lisp/org-exp.el
> @@ -1650,8 +1650,10 @@ When it is nil, all comments will be removed."
> 		  (match-beginning 0) (match-end 0) '(org-protected t))
> 		 (replace-match (format commentsp (match-string 2)) t t))
> 	(goto-char (1+ pos))
> -	(replace-match "")
> -	(goto-char (max (point-min) (1- pos)))))))
> +	(org-if-unprotected
> +	 (replace-match "")
> +	 (goto-char (max (point-min) (1- pos))))))))
> +
>
> (defun org-export-mark-radio-links ()
>   "Find all matches for radio targets and turn them into internal  
> links."
> -- 
> 1.7.0.4

The above patch looks definitely right to me.  In fact, I think the
org-if-unprotected should be around the entire content of the while
loop - with an additional fix to make sure search is resumed not
from the beginning of location of a match that has not been processed,
that would create in infinite loop.

>
> From d422f564163e37c51d0727e2992b24b85caf54ea Mon Sep 17 00:00:00 2001
> From: Eric Schulte <schulte.eric@gmail.com>
> Date: Sun, 27 Jun 2010 19:36:14 -0700
> Subject: [PATCH 2/2] org-latex: check for protection before wrapping  
> ": " lines as verbatim
>
> * lisp/org-latex.el (org-export-latex-fixed-width): check for
>  protection before wrapping ": " lines as verbatim
> ---
> lisp/org-latex.el |   28 ++++++++++++++--------------
> 1 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/lisp/org-latex.el b/lisp/org-latex.el
> index 01a4b05..94f04e6 100644
> --- a/lisp/org-latex.el
> +++ b/lisp/org-latex.el
> @@ -1537,20 +1537,20 @@ The conversion is made depending of STRING- 
> BEFORE and STRING-AFTER."
>   "When OPT is non-nil convert fixed-width sections to LaTeX."
>   (goto-char (point-min))
>   (while (re-search-forward "^[ \t]*:\\([ \t]\\|$\\)" nil t)
> -    (if opt
> -	(progn (goto-char (match-beginning 0))
> -	       (insert "\\begin{verbatim}\n")
> -	       (while (looking-at "^\\([ \t]*\\):\\(\\([ \t]\\|$\\).*\\)$")
> -		 (replace-match (concat (match-string 1)
> -					(match-string 2)) t t)
> -		 (forward-line))
> -	       (insert "\\end{verbatim}\n\n"))
> -      (progn (goto-char (match-beginning 0))
> -	     (while (looking-at "^\\([ \t]*\\):\\(\\([ \t]\\|$\\).*\\)$")
> -	       (replace-match (concat "%" (match-string 1)
> -				      (match-string 2)) t t)
> -	       (forward-line))))))
> -
> +    (org-if-unprotected
> +     (if opt
> +	 (progn (goto-char (match-beginning 0))
> +		(insert "\\begin{verbatim}\n")
> +		(while (looking-at "^\\([ \t]*\\):\\(\\([ \t]\\|$\\).*\\)$")
> +		  (replace-match (concat (match-string 1)
> +					 (match-string 2)) t t)
> +		  (forward-line))
> +		(insert "\\end{verbatim}\n\n"))
> +       (progn (goto-char (match-beginning 0))
> +	      (while (looking-at "^\\([ \t]*\\):\\(\\([ \t]\\|$\\).*\\)$")
> +		(replace-match (concat "%" (match-string 1)
> +				       (match-string 2)) t t)
> +		(forward-line)))))))
>
> (defvar org-table-last-alignment) ; defined in org-table.el
> (defvar org-table-last-column-widths) ; defined in org-table.el
> -- 
> 1.7.0.4

I am not quite certain why this second patch is needed?

- Carsten

Re: Re: [BUG] nested blocks aren't protected on export

[Eric Schulte]

Hi Carsten,

Carsten Dominik <carsten.dominik@gmail.com> writes:

[...]
>
> The above patch looks definitely right to me.  In fact, I think the
> org-if-unprotected should be around the entire content of the while
> loop - with an additional fix to make sure search is resumed not
> from the beginning of location of a match that has not been processed,
> that would create in infinite loop.
>

Great, I've just applied this patch with the fix you described.

>
>>
>> From d422f564163e37c51d0727e2992b24b85caf54ea Mon Sep 17 00:00:00 2001
>> From: Eric Schulte <schulte.eric@gmail.com>
>> Date: Sun, 27 Jun 2010 19:36:14 -0700
>> Subject: [PATCH 2/2] org-latex: check for protection before wrapping
>> ": " lines as verbatim
[...]
>
> I am not quite certain why this second patch is needed?
>

This second patch ensures that we do not nest verbatim environments on
latex export, for example w/o this patch the following org-mode

--8<---------------cut here---------------start------------->8---
#+begin_src org
  ,* escaped org-mode markup
  
  ,this should be exported as is
  ,#+results: escaping-example
  ,: 24
#+end_src
--8<---------------cut here---------------end--------------->8---

exports to the following LaTeX

--8<---------------cut here---------------start------------->8---
\begin{verbatim}
* escaped org-mode markup

this should be exported as is
#+results: escaping-example
\begin{verbatim}
 24
\end{verbatim}

\end{verbatim}
--8<---------------cut here---------------end--------------->8---

I'll wait to hear from you before doing anything with this second patch.

Thanks -- Eric

>
> - Carsten

Re: Re: [BUG] nested blocks aren't protected on export

[Carsten Dominik]

On Jun 28, 2010, at 5:04 PM, Eric Schulte wrote:

> Hi Carsten,
>
> Carsten Dominik <carsten.dominik@gmail.com> writes:
>
> [...]
>>
>> The above patch looks definitely right to me.  In fact, I think the
>> org-if-unprotected should be around the entire content of the while
>> loop - with an additional fix to make sure search is resumed not
>> from the beginning of location of a match that has not been  
>> processed,
>> that would create in infinite loop.
>>
>
> Great, I've just applied this patch with the fix you described.
>
>>
>>>
>>> From d422f564163e37c51d0727e2992b24b85caf54ea Mon Sep 17 00:00:00  
>>> 2001
>>> From: Eric Schulte <schulte.eric@gmail.com>
>>> Date: Sun, 27 Jun 2010 19:36:14 -0700
>>> Subject: [PATCH 2/2] org-latex: check for protection before wrapping
>>> ": " lines as verbatim
> [...]
>>
>> I am not quite certain why this second patch is needed?
>>
>
> This second patch ensures that we do not nest verbatim environments on
> latex export, for example w/o this patch the following org-mode
>
> --8<---------------cut here---------------start------------->8---
> #+begin_src org
>  ,* escaped org-mode markup
>
>  ,this should be exported as is
>  ,#+results: escaping-example
>  ,: 24
> #+end_src
> --8<---------------cut here---------------end--------------->8---
>
> exports to the following LaTeX
>
> --8<---------------cut here---------------start------------->8---
> \begin{verbatim}
> * escaped org-mode markup
>
> this should be exported as is
> #+results: escaping-example
> \begin{verbatim}
> 24
> \end{verbatim}
>
> \end{verbatim}
> --8<---------------cut here---------------end--------------->8---
>
> I'll wait to hear from you before doing anything with this second  
> patch.

For now I don't see anything wrong with this.  The fastest
way to find out is to put it into master and watch the list :-)
Please go ahead and do that.

Thanks.

- Carsten

Re: Re: [BUG] nested blocks aren't protected on export

[Eric Schulte]

Carsten Dominik <carsten.dominik@gmail.com> writes:

[...]
>
> For now I don't see anything wrong with this.  The fastest
> way to find out is to put it into master and watch the list :-)
> Please go ahead and do that.
>

Great, I'll go ahead and try this. Thanks -- Eric

Re: Re: [BUG] nested blocks aren't protected on export

[Eric Schulte]

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

Carsten Dominik <carsten.dominik@gmail.com> writes:

[...]
>
> For now I don't see anything wrong with this.  The fastest
> way to find out is to put it into master and watch the list :-)
> Please go ahead and do that.
>

I think this patch may have uncovered a bug in the export preprocessing
which was previously being covered up by the over-eager comment pruning.

I've now got another patch [1] which fixes the bug in
`org-export-mark-blockquote-verse-center' which was leaving #+end_quote
lines littered in the pre-processed files.

If this looks good to you please do apply it, I'll run it locally in the
meantime to see if any unexpected behavior develops.

Thanks -- Eric

>
> Thanks.
>
> - Carsten

Footnotes: 
[1]  

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-org-exp-ensure-that-end_quote-lines-are-removed.patch --]
[-- Type: text/x-diff, Size: 1106 bytes --]

From 251647d34f599dd025bb08376c0a3eabac604c9d Mon Sep 17 00:00:00 2001
From: Eric Schulte <schulte.eric@gmail.com>
Date: Mon, 28 Jun 2010 12:52:44 -0700
Subject: [PATCH] org-exp: ensure that #+end_quote lines are removed

* lisp/org-exp.el (org-export-mark-blockquote-verse-center): ensure
  that the end_quote line is removed during buffer preprocessing
---
 lisp/org-exp.el |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/lisp/org-exp.el b/lisp/org-exp.el
index f0c11d6..1cd8fc2 100644
--- a/lisp/org-exp.el
+++ b/lisp/org-exp.el
@@ -1569,7 +1569,8 @@ These special cookies will later be interpreted by the backend."
 	    beg1 (1+ (match-end 0)))
       (when (re-search-forward (concat "^[ \t]*#\\+end_" type "\\>.*") nil t)
 	(setq end (+ (point-at-eol) (if (looking-at "\n$") 1 0))
-	      end1 (1- (match-beginning 0)))
+	      end1 (save-excursion (goto-char (1- (match-beginning 0)))
+				   (point-at-bol)))
 	(setq content (org-remove-indentation (buffer-substring beg1 end1)))
 	(setq content (concat "ORG-" (upcase t1) "-START\n"
 			      content "\n"
-- 
1.7.0.4


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

_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Re: [BUG] nested blocks aren't protected on export

[Carsten Dominik]

Hi Eric,

On Jun 28, 2010, at 9:59 PM, Eric Schulte wrote:

> Carsten Dominik <carsten.dominik@gmail.com> writes:
>
> [...]
>>
>> For now I don't see anything wrong with this.  The fastest
>> way to find out is to put it into master and watch the list :-)
>> Please go ahead and do that.
>>
>
> I think this patch may have uncovered a bug in the export  
> preprocessing
> which was previously being covered up by the over-eager comment  
> pruning.
>
> I've now got another patch [1] which fixes the bug in
> `org-export-mark-blockquote-verse-center' which was leaving # 
> +end_quote
> lines littered in the pre-processed files.
>
> If this looks good to you please do apply it, I'll run it locally in  
> the
> meantime to see if any unexpected behavior develops.
>
> Thanks -- Eric
>
>>
>> Thanks.
>>
>> - Carsten
>
> Footnotes:
> [1]  From 251647d34f599dd025bb08376c0a3eabac604c9d Mon Sep 17  
> 00:00:00 2001
> From: Eric Schulte <schulte.eric@gmail.com>
> Date: Mon, 28 Jun 2010 12:52:44 -0700
> Subject: [PATCH] org-exp: ensure that #+end_quote lines are removed
>
> * lisp/org-exp.el (org-export-mark-blockquote-verse-center): ensure
>  that the end_quote line is removed during buffer preprocessing
> ---
> lisp/org-exp.el |    3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/lisp/org-exp.el b/lisp/org-exp.el
> index f0c11d6..1cd8fc2 100644
> --- a/lisp/org-exp.el
> +++ b/lisp/org-exp.el
> @@ -1569,7 +1569,8 @@ These special cookies will later be  
> interpreted by the backend."
> 	    beg1 (1+ (match-end 0)))
>       (when (re-search-forward (concat "^[ \t]*#\\+end_" type "\ 
> \>.*") nil t)
> 	(setq end (+ (point-at-eol) (if (looking-at "\n$") 1 0))
> -	      end1 (1- (match-beginning 0)))
> +	      end1 (save-excursion (goto-char (1- (match-beginning 0)))
> +				   (point-at-bol)))
> 	(setq content (org-remove-indentation (buffer-substring beg1 end1)))
> 	(setq content (concat "ORG-" (upcase t1) "-START\n"
> 			      content "\n"
> -- 
> 1.7.0.4

I think the better fix woud be

diff --git a/lisp/org-exp.el b/lisp/org-exp.el
index f0c11d6..23fb07b 100644
--- a/lisp/org-exp.el
+++ b/lisp/org-exp.el
@@ -1568,8 +1568,8 @@ These special cookies will later be interpreted  
by the bac
        (setq beg (match-beginning 0)
             beg1 (1+ (match-end 0)))
        (when (re-search-forward (concat "^[ \t]*#\\+end_" type "\ 
\>.*") nil t)
-       (setq end (+ (point-at-eol) (if (looking-at "\n$") 1 0))
-             end1 (1- (match-beginning 0)))
+       (setq end1 (1- (match-beginning 0))
+             end (+ (point-at-eol) (if (looking-at "\n$") 1 0)))
         (setq content (org-remove-indentation (buffer-substring beg1  
end1)))
         (setq content (concat "ORG-" (upcase t1) "-START\n"
                               content "\n"


The reason why this fails seems to be because of the looking-at.
When this code was first written, (match-beginning 0) referred to
the earlier regexp match, but the looking-at, if it matches,
changes the meaning of that form.

Could you please try if my patch works as well, and if yes apply it?

Thanks.

- Carsten



>

- Carsten

Re: Re: [BUG] nested blocks aren't protected on export

[Eric Schulte]

Carsten Dominik <carsten.dominik@gmail.com> writes:

[...]
>
> The reason why this fails seems to be because of the looking-at.
> When this code was first written, (match-beginning 0) referred to
> the earlier regexp match, but the looking-at, if it matches,
> changes the meaning of that form.
>
> Could you please try if my patch works as well, and if yes apply it?
>

This does work, it's now applied.

Thanks -- Eric

Re: Re: [BUG] nested blocks aren't protected on export

[Nicolas Goaziou]

Hello,

>>>>> Carsten Dominik writes:

> The above patch looks definitely right to me.  In fact, I think the
> org-if-unprotected should be around the entire content of the while
> loop - with an additional fix to make sure search is resumed not
> from the beginning of location of a match that has not been processed,
> that would create in infinite loop.

I had removed that protection check in a patch before: I think that
comments should be removed (or transformed) during export, whatever
their content is. After all, they are only comments. Any protection
check is useless there.

Now, if blocks get caught by the comment search loop, then some part
of org-mode is not doing its job as #+begin_src isn't a comment
according to the documentation. So, what part is seeing them as
comments ?

I think this first patch may be a quick fix, but it only obfuscates
the true problem.

Regards,

-- 
Nicolas Goaziou

Re: Re: [BUG] nested blocks aren't protected on export

[Eric Schulte]

Hi Nicolas,

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

> Hello,
>
>>>>>> Carsten Dominik writes:
>
>> The above patch looks definitely right to me.  In fact, I think the
>> org-if-unprotected should be around the entire content of the while
>> loop - with an additional fix to make sure search is resumed not
>> from the beginning of location of a match that has not been processed,
>> that would create in infinite loop.
>
> I had removed that protection check in a patch before: I think that
> comments should be removed (or transformed) during export, whatever
> their content is. After all, they are only comments. Any protection
> check is useless there.
>

I disagree, sometimes what looks like a comment is actually content
(see below)

>
> Now, if blocks get caught by the comment search loop, then some part
> of org-mode is not doing its job as #+begin_src isn't a comment
> according to the documentation. So, what part is seeing them as
> comments ?
>
> I think this first patch may be a quick fix, but it only obfuscates
> the true problem.
>

I would disagree here.  There *is* a case where a protected comment
should be retained in the export.  For example, if I'm writing a
document in which I want to discuss Org-mode markup.  It should be
possible for me to include verbatim Org-mode code in my document,
through the use of e.g.

  #+begin_src org
    ,* example org

    ,# this is a comment
    ,this is not a comment
  #+end_src

however without the protection check, the comment would be removed.  If
there is a problem with comments being marked as protected when they
shouldn't be, then that should be fixed where the protection is being
applied, but I believe that the protection check in this patch is
required.

Best -- Eric

>
> Regards,

Re: Re: [BUG] nested blocks aren't protected on export

[Nicolas Goaziou]

>>>>> Eric Schulte writes:
> I would disagree here.  There *is* a case where a protected comment
> should be retained in the export.  For example, if I'm writing a
> document in which I want to discuss Org-mode markup.  It should be
> possible for me to include verbatim Org-mode code in my document,
> through the use of e.g.

>   #+begin_src org
>     ,* example org

>     ,# this is a comment
>     ,this is not a comment
>   #+end_src

> however without the protection check, the comment would be removed.  If
> there is a problem with comments being marked as protected when they
> shouldn't be, then that should be fixed where the protection is being
> applied, but I believe that the protection check in this patch is
> required.

Ok, I get your point. I wasn't thinking recursively.

Regards,

--
Nicolas