From: Achim Gratz <Stromeko@Nexgo.DE>
To: emacs-orgmode@gnu.org
Subject: Re: [BUG] [ODT] Annotations break paragraphs
Date: Thu, 28 Mar 2013 20:12:06 +0100 [thread overview]
Message-ID: <kj24jq$e56$1@ger.gmane.org> (raw)
In-Reply-To: <87vc8by4ci.fsf@gmail.com>
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 :-)
next prev parent reply other threads:[~2013-03-28 19:11 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-21 21:18 [BUG] [ODT] Annotations break paragraphs Christian Moe
2013-03-25 5:59 ` Samuel Wales
2013-03-25 10:29 ` Christian Moe
2013-03-25 10:40 ` Achim Gratz
2013-03-25 15:12 ` Bastien
2013-03-25 16:12 ` Christian Moe
2013-03-25 16:17 ` Bastien
2013-03-25 16:27 ` Achim Gratz
2013-03-25 17:39 ` Christian Moe
2013-03-25 18:54 ` Bastien
2013-03-25 20:26 ` Christian Moe
2013-03-25 17:05 ` Bastien
2013-03-25 17:13 ` Achim Gratz
2013-03-25 20:10 ` Nicolas Goaziou
2013-03-25 21:12 ` Christian Moe
2013-03-25 20:00 ` Christian Moe
2013-03-25 21:56 ` Bastien
2013-03-25 22:15 ` Nicolas Goaziou
2013-03-26 6:28 ` Achim Gratz
2013-03-27 15:48 ` Nicolas Goaziou
2013-03-28 6:24 ` Achim Gratz
2013-03-28 14:41 ` Nicolas Goaziou
2013-03-28 19:12 ` Achim Gratz [this message]
2013-03-28 20:58 ` Christian Moe
2013-03-28 23:04 ` Christian Moe
2013-03-26 9:38 ` Christian Moe
2013-03-27 22:33 ` Nicolas Goaziou
2013-03-28 8:40 ` Christian Moe
2013-03-28 9:46 ` Christian Moe
2013-03-25 22:36 ` Christian Moe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='kj24jq$e56$1@ger.gmane.org' \
--to=stromeko@nexgo.de \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).