Re: [new exporter] 2 questions

[Nicolas Goaziou <n.goaziou@gmail.com>]

Achim Gratz <Stromeko@nexgo.de> 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