From: Achim Gratz <Stromeko@nexgo.de>
To: emacs-orgmode@gnu.org
Subject: Re: [new exporter] 2 questions
Date: Sat, 23 Feb 2013 14:04:36 +0100 [thread overview]
Message-ID: <87fw0nw597.fsf@Rainer.invalid> (raw)
In-Reply-To: 874nh3jjg4.fsf@gmail.com
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
next prev parent reply other threads:[~2013-02-23 13:05 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-22 18:06 [new exporter] 2 questions henry atting
2013-02-22 19:04 ` Nicolas Goaziou
2013-02-22 19:38 ` henry atting
2013-02-22 19:42 ` Nicolas Goaziou
2013-02-22 20:13 ` henry atting
2013-02-22 20:19 ` Nicolas Goaziou
2013-02-22 20:31 ` henry atting
2013-02-22 20:33 ` Nicolas Goaziou
2013-02-22 20:39 ` henry atting
2013-02-22 21:39 ` Achim Gratz
2013-02-23 8:21 ` Bastien
2013-02-23 10:52 ` Nicolas Goaziou
2013-02-23 12:14 ` Achim Gratz
2013-02-23 12:36 ` Nicolas Goaziou
2013-02-23 13:04 ` Achim Gratz [this message]
2013-02-23 13:35 ` Nicolas Goaziou
2013-02-23 15:21 ` Achim Gratz
2013-02-23 15:31 ` Nicolas Goaziou
2013-02-23 16:35 ` Achim Gratz
2013-02-23 17:39 ` Nicolas Goaziou
2013-02-23 18:40 ` Achim Gratz
2013-02-24 9:09 ` Nicolas Goaziou
2013-02-24 10:31 ` Achim Gratz
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=87fw0nw597.fsf@Rainer.invalid \
--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).