From mboxrd@z Thu Jan 1 00:00:00 1970 From: Achim Gratz Subject: Re: [BUG] [ODT] Annotations break paragraphs Date: Thu, 28 Mar 2013 20:12:06 +0100 Message-ID: References: <871ub3o6mn.fsf@bzg.ath.cx> <87ip4f9zqa.fsf@bzg.ath.cx> <87r4j35ejb.fsf@bzg.ath.cx> <87ip4fxh1e.fsf@gmail.com> <87k3osg7xg.fsf@gmail.com> <87vc8by4ci.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([208.118.235.92]:50707) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ULIEI-0008OX-V5 for emacs-orgmode@gnu.org; Thu, 28 Mar 2013 15:11:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ULIEH-00014g-04 for emacs-orgmode@gnu.org; Thu, 28 Mar 2013 15:11:18 -0400 Received: from plane.gmane.org ([80.91.229.3]:51527) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ULIEG-00014Y-PM for emacs-orgmode@gnu.org; Thu, 28 Mar 2013 15:11:16 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ULIEW-0002e6-T2 for emacs-orgmode@gnu.org; Thu, 28 Mar 2013 20:11:32 +0100 Received: from p578f1aad.dip.t-dialin.net ([87.143.26.173]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Mar 2013 20:11:32 +0100 Received: from Stromeko by p578f1aad.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 28 Mar 2013 20:11:32 +0100 In-Reply-To: <87vc8by4ci.fsf@gmail.com> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org 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<---- begin_p-block end_p-block begin_p-block end_p-block begin_p-block 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 :-)