syntax for blocks that the exporter should not render?

syntax for blocks that the exporter should not render?

[Matt Price]

Hi,

certain lines are not rendered by the org exporter, but are instead
interpreted as instructions, e.g.:

#+AUTHOR: Matt Price

I'm using org2blog/wp, which is only partially converted to the new
exporter.  It works pretty well, but not perfectly.  It has the neat
feature that, when I insert a link to a local image, it will upload
that image to wordpress and link to the uploaded file.  TO keep track
of the location of those images, it writes lines like this to the org
file:

#+/home/matt/Matt_headshots/Matt Price/IMG_9367_.jpg
http://2013.hackinghistory.ca/wp-content/uploads/2013/08/wpid-IMG_9367_2.jpg

Recently I've noticed that these lines are actually being rendered by
the underlying html exporter before export.  I can (sort of) fix this
by adding a filter to the exporter (thanks again Nicolas!):

---------
(add-to-list 'org-export-filter-paragraph-functions
'matt-org-export-filter-paragraph-function)
(defun matt-org-export-filter-paragraph-function (paragraph backend info)
  "removes comments from export"
  (when (org-export-derived-backend-p backend 'html)
    (replace-regexp-in-string "^#\+.*$" "" paragraph)
))

but it would be better if I could get the underlying exporter to just
ignore these lines. I thought that the leading #+ was enough to get
org to treat these lines as non-text -- but I guess I'm wrong!  Anyone
know a solution?

Thanks!
Matt

Re: syntax for blocks that the exporter should not render?

[Jambunathan K]

Matt Price <moptop99@gmail.com> writes:

> #+ was enough to get org to treat these lines as non-text

Try adding a space character after #+.

Re: syntax for blocks that the exporter should not render?

[Suvayu Ali]

On Tue, Sep 03, 2013 at 11:32:33AM -0400, Matt Price wrote:
> 
> #+/home/matt/Matt_headshots/Matt Price/IMG_9367_.jpg
> http://2013.hackinghistory.ca/wp-content/uploads/2013/08/wpid-IMG_9367_2.jpg

 [...chomp...chomp...chomp...]

> ignore these lines. I thought that the leading #+ was enough to get
> org to treat these lines as non-text -- but I guess I'm wrong!  Anyone
> know a solution?

Have you tried customising the leading string to "# " instead?  That
would make them comments and will be ignored by the exporter.

-- 
Suvayu

Open source is the future. It sets us free.

Re: syntax for blocks that the exporter should not render?

[Carsten Dominik]

On 3.9.2013, at 17:32, Matt Price <moptop99@gmail.com> wrote:

> Hi,
> 
> certain lines are not rendered by the org exporter, but are instead
> interpreted as instructions, e.g.:
> 
> #+AUTHOR: Matt Price
> 
> I'm using org2blog/wp, which is only partially converted to the new
> exporter.  It works pretty well, but not perfectly.  It has the neat
> feature that, when I insert a link to a local image, it will upload
> that image to wordpress and link to the uploaded file.  TO keep track
> of the location of those images, it writes lines like this to the org
> file:
> 
> #+/home/matt/Matt_headshots/Matt Price/IMG_9367_.jpg
> http://2013.hackinghistory.ca/wp-content/uploads/2013/08/wpid-IMG_9367_2.jpg
> 
> Recently I've noticed that these lines are actually being rendered by
> the underlying html exporter before export.

I don't think this is the right behavior, such lines should not be rendered.
Suvayu is right, with a space after the # they are treated as commendt, but I think
they should also be ignored with the plus.

Nicolas, what is the reasoning behind rendering them?

Thanks

- Carsten

>  I can (sort of) fix this
> by adding a filter to the exporter (thanks again Nicolas!):
> 
> ---------
> (add-to-list 'org-export-filter-paragraph-functions
> 'matt-org-export-filter-paragraph-function)
> (defun matt-org-export-filter-paragraph-function (paragraph backend info)
>  "removes comments from export"
>  (when (org-export-derived-backend-p backend 'html)
>    (replace-regexp-in-string "^#\+.*$" "" paragraph)
> ))
> 
> but it would be better if I could get the underlying exporter to just
> ignore these lines. I thought that the leading #+ was enough to get
> org to treat these lines as non-text -- but I guess I'm wrong!  Anyone
> know a solution?
> 
> Thanks!
> Matt
> 

Re: syntax for blocks that the exporter should not render?

[Nicolas Goaziou]

Hello,

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

> On 3.9.2013, at 17:32, Matt Price <moptop99@gmail.com> wrote:
>
>> Hi,
>> 
>> certain lines are not rendered by the org exporter, but are instead
>> interpreted as instructions, e.g.:
>> 
>> #+AUTHOR: Matt Price
>> 
>> I'm using org2blog/wp, which is only partially converted to the new
>> exporter.  It works pretty well, but not perfectly.  It has the neat
>> feature that, when I insert a link to a local image, it will upload
>> that image to wordpress and link to the uploaded file.  TO keep track
>> of the location of those images, it writes lines like this to the org
>> file:
>> 
>> #+/home/matt/Matt_headshots/Matt Price/IMG_9367_.jpg
>> http://2013.hackinghistory.ca/wp-content/uploads/2013/08/wpid-IMG_9367_2.jpg
>> 
>> Recently I've noticed that these lines are actually being rendered by
>> the underlying html exporter before export.
>
> I don't think this is the right behavior, such lines should not be rendered.
> Suvayu is right, with a space after the # they are treated as commendt, but I think
> they should also be ignored with the plus.
>
> Nicolas, what is the reasoning behind rendering them?

Because this isn't valid Org syntax, so it is treated as regular text
(i.e. a paragraph). Something similar happens for unbalanced blocks:

  * H

  #+begin_example

  * H2

In the example above, "#+begin_example" is treated as a paragraph.

In both cases, silently ignoring them could cause more trouble that it
would solve.


Regards,

-- 
Nicolas Goaziou

Re: syntax for blocks that the exporter should not render?

[Carsten Dominik]

On Sep 5, 2013, at 12:09 PM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:

> Hello,
> 
> Carsten Dominik <carsten.dominik@gmail.com> writes:
> 
>> On 3.9.2013, at 17:32, Matt Price <moptop99@gmail.com> wrote:
>> 
>>> Hi,
>>> 
>>> certain lines are not rendered by the org exporter, but are instead
>>> interpreted as instructions, e.g.:
>>> 
>>> #+AUTHOR: Matt Price
>>> 
>>> I'm using org2blog/wp, which is only partially converted to the new
>>> exporter.  It works pretty well, but not perfectly.  It has the neat
>>> feature that, when I insert a link to a local image, it will upload
>>> that image to wordpress and link to the uploaded file.  TO keep track
>>> of the location of those images, it writes lines like this to the org
>>> file:
>>> 
>>> #+/home/matt/Matt_headshots/Matt Price/IMG_9367_.jpg
>>> http://2013.hackinghistory.ca/wp-content/uploads/2013/08/wpid-IMG_9367_2.jpg
>>> 
>>> Recently I've noticed that these lines are actually being rendered by
>>> the underlying html exporter before export.
>> 
>> I don't think this is the right behavior, such lines should not be rendered.
>> Suvayu is right, with a space after the # they are treated as commendt, but I think
>> they should also be ignored with the plus.
>> 
>> Nicolas, what is the reasoning behind rendering them?
> 
> Because this isn't valid Org syntax, so it is treated as regular text
> (i.e. a paragraph). Something similar happens for unbalanced blocks:
> 
>  * H
> 
>  #+begin_example
> 
>  * H2
> 
> In the example above, "#+begin_example" is treated as a paragraph.
> 
> In both cases, silently ignoring them could cause more trouble that it
> would solve.

So in a way this is a "syntax error" message. :)

OK, I get that point.  Is that behaviour documented?

Thanks

- Carsten

Re: syntax for blocks that the exporter should not render?

[Suvayu Ali]

Hi Carsten,

On Thu, Sep 05, 2013 at 01:27:57PM +0200, Carsten Dominik wrote:
> 
> On Sep 5, 2013, at 12:09 PM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
> 
> >>> #+/home/matt/Matt_headshots/Matt Price/IMG_9367_.jpg
> >>> http://2013.hackinghistory.ca/wp-content/uploads/2013/08/wpid-IMG_9367_2.jpg
> >> 
> >> I don't think this is the right behavior, such lines should not be rendered.
> >> Suvayu is right, with a space after the # they are treated as commendt, but I think
> >> they should also be ignored with the plus.
> >> 
> >> Nicolas, what is the reasoning behind rendering them?
> > 
> > Because this isn't valid Org syntax, so it is treated as regular text
> > (i.e. a paragraph). Something similar happens for unbalanced blocks:
> 
> So in a way this is a "syntax error" message. :)
> 
> OK, I get that point.  Is that behaviour documented?

I think it is more of a "I don't recognise this as special syntax; it
must be text".  In that case, I'm not sure what can be documented, one
can have infinitely many text blurbs which look very similar to valid
Org syntax but isn't.

I have noticed quite a few posts on the list with this kind of
misunderstanding.  I think the confusion arises from thinking of special
keywords like "#+options:", "#+attr_latex:", etc as comments.  AFAIU,
they are not.  Lines starting with "#+" are possible keywords, whereas
lines starting with "# " are comments.

I can see how that can be confusing, but can't think of a way to resolve
this.  I have two possibilities in mind:
1. change "# " to something more distict like: "//", or "##",
2. use different faces for the two.

(1) is probably too big a change, whereas (2) might be feasible.

Nicolas will probably have a better feeling about what is more
appropriate here.

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.

Re: syntax for blocks that the exporter should not render?

[Carsten Dominik]

On Sep 5, 2013, at 1:43 PM, Suvayu Ali <fatkasuvayu+linux@gmail.com> wrote:

> Hi Carsten,
> 
> On Thu, Sep 05, 2013 at 01:27:57PM +0200, Carsten Dominik wrote:
>> 
>> On Sep 5, 2013, at 12:09 PM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
>> 
>>>>> #+/home/matt/Matt_headshots/Matt Price/IMG_9367_.jpg
>>>>> http://2013.hackinghistory.ca/wp-content/uploads/2013/08/wpid-IMG_9367_2.jpg
>>>> 
>>>> I don't think this is the right behavior, such lines should not be rendered.
>>>> Suvayu is right, with a space after the # they are treated as commendt, but I think
>>>> they should also be ignored with the plus.
>>>> 
>>>> Nicolas, what is the reasoning behind rendering them?
>>> 
>>> Because this isn't valid Org syntax, so it is treated as regular text
>>> (i.e. a paragraph). Something similar happens for unbalanced blocks:
>> 
>> So in a way this is a "syntax error" message. :)
>> 
>> OK, I get that point.  Is that behaviour documented?
> 
> I think it is more of a "I don't recognise this as special syntax; it
> must be text".  In that case, I'm not sure what can be documented, one
> can have infinitely many text blurbs which look very similar to valid
> Org syntax but isn't.
> 
> I have noticed quite a few posts on the list with this kind of
> misunderstanding.  I think the confusion arises from thinking of special
> keywords like "#+options:", "#+attr_latex:", etc as comments.  AFAIU,
> they are not.  Lines starting with "#+" are possible keywords, whereas
> lines starting with "# " are comments.

Yes, and I just checked what we have in the manual:

Lines starting with zero or more whitespace characters followed by one
@samp{#} and a whitespace are treated as comments and will never be exported.

So indeed, the white space after the # is in the manual.  I had forgotten about this.

> 
> I can see how that can be confusing, but can't think of a way to resolve
> this.  I have two possibilities in mind:
> 1. change "# " to something more distict like: "//", or "##",
> 2. use different faces for the two.

Another way to do this would be that every line starting with "#" (no space) is a comment line, except when it is starting with "#+".  This was how I used to think about lines starting with "#".  BUt it is not bad the way it is now - we just need to be aware and tell people - we just did.

Thanks

- Carsten

> 
> (1) is probably too big a change, whereas (2) might be feasible.
> 
> Nicolas will probably have a better feeling about what is more
> appropriate here.
> 
> Cheers,
> 
> -- 
> Suvayu
> 
> Open source is the future. It sets us free.
> 

Re: syntax for blocks that the exporter should not render?

[Carsten Dominik]

On Sep 3, 2013, at 5:59 PM, Jambunathan K <kjambunathan@gmail.com> wrote:

> Matt Price <moptop99@gmail.com> writes:
> 
>> #+ was enough to get org to treat these lines as non-text
> 
> Try adding a space character after #+.

Nope, this will not work, see the rest of the thread.

- Carsten

Re: syntax for blocks that the exporter should not render?

[Matt Price]

On Thu, Sep 5, 2013 at 6:09 AM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
> Hello,
>
> Carsten Dominik <carsten.dominik@gmail.com> writes:
>
>> On 3.9.2013, at 17:32, Matt Price <moptop99@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> certain lines are not rendered by the org exporter, but are instead
>>> interpreted as instructions, e.g.:
>>>
>>> #+AUTHOR: Matt Price
>>>
>>> I'm using org2blog/wp, which is only partially converted to the new
>>> exporter.  It works pretty well, but not perfectly.  It has the neat
>>> feature that, when I insert a link to a local image, it will upload
>>> that image to wordpress and link to the uploaded file.  TO keep track
>>> of the location of those images, it writes lines like this to the org
>>> file:
>>>
>>> #+/home/matt/Matt_headshots/Matt Price/IMG_9367_.jpg
>>> http://2013.hackinghistory.ca/wp-content/uploads/2013/08/wpid-IMG_9367_2.jpg
>>>
>>> Recently I've noticed that these lines are actually being rendered by
>>> the underlying html exporter before export.
>>
>> I don't think this is the right behavior, such lines should not be rendered.
>> Suvayu is right, with a space after the # they are treated as commendt, but I think
>> they should also be ignored with the plus.
>>
>> Nicolas, what is the reasoning behind rendering them?
>
> Because this isn't valid Org syntax, so it is treated as regular text
> (i.e. a paragraph). Something similar happens for unbalanced blocks:
>
>   * H
>
>   #+begin_example
>
>   * H2
>
> In the example above, "#+begin_example" is treated as a paragraph.
>
> In both cases, silently ignoring them could cause more trouble that it
> would solve.

Nicolas, can you help clarify under what conditions it's appropriate
to use the #+ syntax, and when to use '#' on its own?  I think
org2blog/wp uses #+ precisely in order to mark those comments as
org-related.  If you cna just tell me what the appropriate behaviour
is I will submit a patch to puneeth.

m


>
>
> Regards,
>
> --
> Nicolas Goaziou

Re: syntax for blocks that the exporter should not render?

[Matt Price]

On Thu, Sep 5, 2013 at 7:57 AM, Carsten Dominik
<carsten.dominik@gmail.com> wrote:
>
> On Sep 5, 2013, at 1:43 PM, Suvayu Ali <fatkasuvayu+linux@gmail.com> wrote:
>
>> Hi Carsten,
>>
>> On Thu, Sep 05, 2013 at 01:27:57PM +0200, Carsten Dominik wrote:
>>>
>>> On Sep 5, 2013, at 12:09 PM, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
>>>
>>>>>> #+/home/matt/Matt_headshots/Matt Price/IMG_9367_.jpg
>>>>>> http://2013.hackinghistory.ca/wp-content/uploads/2013/08/wpid-IMG_9367_2.jpg
>>>>>
>>>>> I don't think this is the right behavior, such lines should not be rendered.
>>>>> Suvayu is right, with a space after the # they are treated as commendt, but I think
>>>>> they should also be ignored with the plus.
>>>>>
>>>>> Nicolas, what is the reasoning behind rendering them?
>>>>
>>>> Because this isn't valid Org syntax, so it is treated as regular text
>>>> (i.e. a paragraph). Something similar happens for unbalanced blocks:
>>>
>>> So in a way this is a "syntax error" message. :)
>>>
>>> OK, I get that point.  Is that behaviour documented?
>>
>> I think it is more of a "I don't recognise this as special syntax; it
>> must be text".  In that case, I'm not sure what can be documented, one
>> can have infinitely many text blurbs which look very similar to valid
>> Org syntax but isn't.
>>
>> I have noticed quite a few posts on the list with this kind of
>> misunderstanding.  I think the confusion arises from thinking of special
>> keywords like "#+options:", "#+attr_latex:", etc as comments.  AFAIU,
>> they are not.  Lines starting with "#+" are possible keywords, whereas
>> lines starting with "# " are comments.

(sorry, posted my last msg before I saw the more recent contributions)
So how would you suggest org2blog keep track of the relationship
between local and uploaded files?
Should it define a new keyword (perhaps" #+remote:" )?  And if so how
is that best done? Quickly looking at "Export Options (12.2) in the
manual I don't see a built-in mechanism for defining backend-specific
options.  Something like "#+ATTR_BLOG: remote" might do the trick, but
adding multiple links to such a line would be cumbersome, wouldn't it?

Thanks again for your help clarifying this.