emacs-orgmode
[Top][All Lists]
Advanced

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

Re: [O] [BUG] [ODT] Annotations break paragraphs


From: Achim Gratz
Subject: Re: [O] [BUG] [ODT] Annotations break paragraphs
Date: Thu, 28 Mar 2013 07:24:09 +0100
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4

Am 27.03.2013 16:48, schrieb Nicolas Goaziou:
So this would be a single P-Block with an annotation inside:

----8<----
    There is an annotation by the original author here
    #+BEGIN_ANNOTATION
      I never meant to break this paragraph.
    #+END_ANNOTATION
    in the middle of the paragraph.
---->8----

It wouldn't allow paragraphs within the annotation.

???

----8<----
    There is an annotation by the original author here
    #+BEGIN_ANNOTATION
      I never meant to break this paragraph.

      But here's a second one in the annotation,
      still not braking the outer paragraph.
    #+END_ANNOTATION
    in the middle of the paragraph.
---->8----

Anyway, every back-end has its own interpretation of what a paragraph
is. Some back-ends don't even know what a paragraph is. Org cannot fit
them all.

That's why Org can't impose its much more restricted paragraph model on backends with different paragraph models.

On the other hand, as the ox-odt patch somehow demonstrates, it is
possible for a back-end to ignore Org paragraph definition and rolls its
own. It requires some additional code, but I'm open to discussion about
implementing tools in ox.el in order to ease the process.

Yes, and footnotes with paragraphs... Anyway, for me this is the main sticking point with how Org syntax is defined, because it currently implies Org syntax == Backend semantics, which is simply not the case for most if not all backends. Working around this in each and every backend doesn't look appealing.

In any case, I think we ought to keep raw Org syntax as simple as
possible. The current definition of a paragraph is simple enough.

The syntax wouldn't change all that much, except that blank lines would need to be made tokens during parsing.


Regards,
--
Achim.

(on the road :-)




reply via email to

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