emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] comments and attributes


From: Nicolas Goaziou
Subject: Re: [O] comments and attributes
Date: Wed, 01 Feb 2012 14:04:08 +0100

Hello,

Jambunathan K <address@hidden> writes:

> On a related note,
>
> * Example
>
> This 
> is 
> a
> single
> # some comment
> paragraph.
>
>
> This 
> is 
> another
> #+attr_odt: t
> paragraph.
>
> if I parse the above buffer, I get
>
> #+begin_src emacs-lisp
>   (paragraph
>    (:begin 412 :end 431 :contents-begin 412 :contents-end 430 :post-blank 0)
>    "This \nis \na\nsingle")
>   (comment
>    (:begin 431 :end 446 :value "# some comment\n" :post-blank 0))
>   (paragraph
>    (:begin 446 :end 459 :contents-begin 446 :contents-end 456 :post-blank 2)
>    "paragraph.")
>   (paragraph
>    (:begin 459 :end 477 :contents-begin 459 :contents-end 476 :post-blank 0)
>    "This \nis \nanother")
>   (paragraph
>    (:begin 477 :end 502 :contents-begin 491 :contents-end 501 :post-blank 0 
> :attr_odt
>               ("t"))
>    "paragraph.")
> #+end_src
>
> I see that the new export engine treats comment and control lines as par
> breakers. The backends that are in production treats the first paragraph
> as but a single paragraph.

Not the export engine, but the parser. Comment is an element type, as is
Paragraph. Beginning an element ends the previous one.

This has always been true in Org. For example, you may look at
`paragraph-start' and `paragraph-separate' values in an Org buffer:
comments (and many other things) are clearly separating and ending
paragraphs.

Also, it is consistent with other elements. Indeed, consider the
following example:

--8<---------------cut here---------------start------------->8---
: fixed-width line 1
# Commented line
: fixed-width line 2
--8<---------------cut here---------------end--------------->8---

If you use C-c ' on the first fixed-width line, you won't be offered to
edit also the second one.

Though, you're right, current exporter indeed ignores that Org feature.

> There is already a way by which parbreaks can be introduced. Do you
> think there could be some useful behaviour achieved - side by side
> export of images came up in this thread - by not having commented
> elements introduce parbreaks.

I think that it's a mistake to rely on comments to define semantics.

Anyway, I suggested something already about the problem of side by side
paragraphs. What was wrong with it? If it wasn't clear, I'll try to
provide an example. If it was flawed, we may try to improve it.


Regards,

-- 
Nicolas Goaziou



reply via email to

[Prev in Thread] Current Thread [Next in Thread]