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

[Achim Gratz]

Am 28.03.2013 15:41, schrieb Nicolas Goaziou:
> Then you're contradicting yourself, since you also said:
>
>    I suggest to follow the lead of (La)TeX and determine begin and end of
>    such blocks by blank lines.
>
> In your example, the end of the "P-block" isn't at the blank line. My
> comment was on that precise part of your message.

A P-block cannot end inside a special block, just as you don't end a 
paragraph inside an inline footnote.

> > The syntax wouldn't change all that much, except that blank lines would
> > need to be made tokens during parsing.
>
> This is not only about blank lines. Remember your example:
>
>     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.
>
> There is no blank line, and, yet, it should be parsed differently than
> it is actually. Therefore, it's not just about blank lines. It's about
> allowing indirectly paragraphs within paragraphs.

Well, obviously this example erred on the side of brevity: the begin and 
the end of the document impllicitly begin and end the single P-block, 
which was the point.

----8<----
* Heading
** Sub-Heading
*** Sub-Sub-Heading

    Let's start a single paragraph.

    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.

    Here's another paragraph.
---->8----

This would be parsed as:

----8<----
<heading level 1>
<heading level 2>
<heading level 3>
begin_p-block
  <paragraph>
end_p-block
begin_p-block
  <paragraph>
  <annotation>
  <paragraph>
end_p-block
begin_p-block
  <paragraph>
end_p-block
---->8----

> Do not misunderstand me: I agree that the current paragraph model is
> restricted. But remember we're working with plain text which should be
> readable as plain text, not with a full-fledged XML-like markup. The
> strength of this paragraph definition lies in its simplicity. And I am
> impressed about how much is done with such a simple syntax.

Again and maybe I'm expressing myself too poorly, I don't suggest to 
change that model.  It is working well for Org as far as I can tell. 
What I'm suggesting is an extension of that model, ostensibly to help 
supporting more complex models for exporting.  To this end blank lines 
must either be handed explicitly to the exporter and not gobbled up by 
org-element or org-element could extract P-blocks as shown above.

> IMO, this kind of syntax, i.e. mixing blocks and paragraphs, is just
> ugly. It makes it impossible to read property the paragraph and
> emphasizes the annotation, which is counter-productive.

What about tables, images, listings, equations?  You already have that 
very problem (each of those break the paragraph around them) in many 
forms.  You can fix them one by one and tweak heuristics in the exporter 
for the next two years or you can provide a general mechanism to deal 
with that situation.

> A good rule of thumb is that blocks should be used as containers, never
> as inlined elements.

That's why the exported paragraph must be a separate entity from what 
Org calls a paragraph: there are many block elements in Org that can and 
should possibly be expüorted as inlined elements in the what gets 
exported as a paragraph.

> Speaking of inlined elements, I repeat that [note:label] within the
> paragraph should offer a good markup for annotations.

While I agree that this is a good solution for annotations and mimics 
the way inline footnotes work, it introduces a new syntactical element 
only for escaping that limitation.  Now, when you think about LaTeX 
blocks you can't treat them the same easily, but there really is no good 
reason why an equation array should introduce an unwanted paragraph 
boundary in LaTeX (again, I'm not talking about the paragraph boundaries 
in Org).


Regards,
--
Achim.

(on the road :-)

--
Achim.

(on the road :-)