emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [new exporter] 2 questions


From: Achim Gratz
Subject: Re: [O] [new exporter] 2 questions
Date: Sat, 23 Feb 2013 14:04:36 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.93 (gnu/linux)

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!".

> 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.

--8<---------------cut here---------------start------------->8---
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.
--8<---------------cut here---------------end--------------->8---

Org sees that as a paragraph with some wierd ending, 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.

> Also, you're thinking backwards here: the parser doesn't have to think
> about what you're looking at, as it knows it. Alas it can't know what
> you're thinking you're looking at.

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.

> Anyway you can use (org-element-context) to know where point currently
> is.

Thanks.

>> And in all these cases where something inside an object or an element
>> looks like it might be another element or greater element, we do need
>> a way of quoting, I'd say.
>
> No element can be found within an object.

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.
The user found out only after trying to export the document.

> So far, I don't see a need for quoting. In your previous example, you
> know (or should know) that "- " as the first non-white string in a line
> defines an item. You keep wanting to see a mathematical operation,
> probably because you're focused on the LaTeX snippet you're writing, but
> you're wrong wrt Org syntax.

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.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds




reply via email to

[Prev in Thread] Current Thread [Next in Thread]