From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: [new exporter] 2 questions Date: Sat, 23 Feb 2013 14:35:42 +0100 Message-ID: <87vc9ji24x.fsf@gmail.com> References: <87sj4ogr4b.fsf@bye.fritz.box> <87liagjhlm.fsf@gmail.com> <87fw0oxhon.fsf@bye.fritz.box> <87hal4jfuf.fsf@gmail.com> <87a9qwni43.fsf@Rainer.invalid> <87ppzr5ms9.fsf@bzg.ath.cx> <877glzi9or.fsf@gmail.com> <87obfbw7kj.fsf@Rainer.invalid> <874nh3jjg4.fsf@gmail.com> <87fw0nw597.fsf@Rainer.invalid> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:51201) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U9FGk-0002f9-FE for emacs-orgmode@gnu.org; Sat, 23 Feb 2013 08:36:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U9FGf-0001k3-KB for emacs-orgmode@gnu.org; Sat, 23 Feb 2013 08:36:02 -0500 Received: from mail-wi0-f177.google.com ([209.85.212.177]:61996) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U9FGf-0001js-AR for emacs-orgmode@gnu.org; Sat, 23 Feb 2013 08:35:57 -0500 Received: by mail-wi0-f177.google.com with SMTP id hm14so1706241wib.16 for ; Sat, 23 Feb 2013 05:35:56 -0800 (PST) In-Reply-To: <87fw0nw597.fsf@Rainer.invalid> (Achim Gratz's message of "Sat, 23 Feb 2013 14:04:36 +0100") 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: Achim Gratz Cc: emacs-orgmode@gnu.org Achim Gratz writes: > Nicolas Goaziou writes: >> The parser parses Org syntax. If you see something else, unless there is >> an obvious bug, then you are expecting the Org syntax to be different >> from what it is. It's even the goal of the parser: to define the way to >> read Org syntax. > > That's what I said. You also defined "The Way Things Are"(TM) to make > the job of parsing easier and faster. I can also understand that. But > I (sometimes at least) also simply use Org and I run into things that > should have a solution, other than "Don't do that!". I gave you a solution since the beginning of this thread: use a latex environment. >> Some paragraph, something that looks like a link start [[#eisetu][and >> something that looks like a math snippet \(2 + 3 >> - item 1 >> - item 2 > > The example was slightly different and I think that matters for the > discussion. Note that those terms span the better part of a line and > I'm usually using at least 130 chars wide lines. > > Some paragraph, something that looks like a link start [[#eisetu][and > something that looks like a math snippet > # > \[ > R = term1 > - term2 > + term3 > \] > # > end of the paragraph started above. > > Org sees that as a paragraph with some wierd ending, It would be interesting to know what Org judges as weird. > a list with two items and another paragraph with a wierd beginning. > The user doesn't even start to think about it in this way until the > exporter stops with a LaTeX error. Fontification helps (or should help) here. Anyway, this problem is unrelated to the LaTeX exporter, since it only exports what parser parses. > The question is if that simplification in parsing is worth the > unintuitive result. The main reason for this is that the paragraph > parsing doesn't consider objects in the paragraph at all during > parsing. If the objects would be parsed directly when they are > encountered, it would be clear that the two extra terms are not > a list. It /is/ intuitive and quite simple actually. "*" at column 0 starts a headline, "- " at the beginning of a line starts a list[fn:1]... Very often, you know what you're writing just by looking at the beginning of the line. On the other hand, if you allow the first object to start to have precedence over what comes next, you're in big trouble. In fact, you may have to look dozens of lines above only to discover you had started an object before the one you were expecting to write. --8<---------------cut here---------------start------------->8--- ~lorem.... ... a dozen of lines ... \[ R = term 1 - term 2 + term 3 \] end of paragraph or so I think~ --8<---------------cut here---------------end--------------->8--- Here you didn't write a math snippet. Sure, you can add a hack and arbitrary say "Objects are never longer than 3 lines". Then, in this case, you didn't write a math snippet either. Also, if there's no order in which syntactical elements are parsed, the following could as well be a math snippet instead of an headline: --8<---------------cut here---------------start------------->8--- \( * 2 \) --8<---------------cut here---------------end--------------->8--- Sorry, but it has never been the case in Org. Org has always implied classification in syntax. And that's a quite sane behaviour. Otherwise, you can never be sure about what you're writing without memorizing the complete buffer. Again, the current syntax is very regular. It can lead to surprises, I understand that, but far less than with what you expect. > A list was found inside what the user intended to be a LaTeX fragment. > It also made two paragraphs out of what should have been a single one. I disagree with that part. There shouldn't have been a single paragraph, and there isn't. Not in Org syntax, at least. > Or maybe the Org syntax is wrong w.r.t. usability and robustness. The > same issue is encountered often enough with blocks (you've answered > quite a number of those questions): they are suggestive to the user of > being self contained, but Org syntax says they aren't. I call that a > trap for the unwary. I just suggest to learn Org syntax. Any help to upgrade the documentation accordingly and make this task easier is welcome. Regards, [fn:1] Ok, this one has exceptions, like in src blocks, but there's also an explanation. -- Nicolas Goaziou