From: Nicolas Goaziou <n.goaziou@gmail.com>
To: Achim Gratz <Stromeko@nexgo.de>
Cc: emacs-orgmode@gnu.org
Subject: Re: [RFC] Org syntax (draft)
Date: Sun, 10 Mar 2013 00:49:40 +0100 [thread overview]
Message-ID: <878v5wi163.fsf@gmail.com> (raw)
In-Reply-To: <87ppz8upsx.fsf@Rainer.invalid> (Achim Gratz's message of "Sun, 10 Mar 2013 00:16:46 +0100")
Hello,
Achim Gratz <Stromeko@nexgo.de> writes:
> Do you mind if I fix some obvious typos directly on Worg or do you'd
> rather want patches?
Please go ahead. This is on Worg so anyone can improve it.
> Nicolas Goaziou writes:
>> A core concept in this syntax is that only headlines and sections are
>> context-free[1][2]. Every other syntactical part only exists within
>> specific environments.
>
> Blank lines or empty lines are also context-free syntactical elements,
> I'd think.
No, the aren't, as they belong to the broadest element ending before
them. So you need to know what this element is.
>> Three categories are used to classify these environments: “Greater
>> elements”, “elements”, and “objects”, from the broadest scope to the
>> narrowest.
>
> It might be easier to talk about those things if "Greater Element" was
> called "Collection" to perhaps keep with the thingies theme of naming
> the syntax.
Collection could also be ambiguous as a paragraph may be seen as
a collection of objects.
>> The paragraph is the unit of measurement. An element defines
>> syntactical parts that are at the same level as a paragraph, i.e. which
>> cannot contain or be included in a paragraph. An object is a part that
>> could be included in an element. Greater elements are all parts that
>> can contain an element.
>
> Here's my main contention with that model: I think there should be an
> greater element, maybe named "paragraph block" that translates into a
> paragraph at the backend level. Most backends will have a paragraph
> model that is much less limited than what the current definition of an
> Org paragraph is. This could be optionally be an implicit greater
> block that is defined by the presence or absence of blank lines between
> elements, I'd think.
I don't get it. What would be the exact definition of a "paragraph
block"? What limitations are you talking about?
>> 3.1 Greater Blocks
>> ──────────────────
>
> The same naming confusion as with the various "elements", for now I'd
> link to think of these as "Box".
This naming was for the org-syntax file only. "Greater blocks" means
nothing for org-element.el, but "center block", "quote block", "special
block" do.
>> Greater blocks consist in the following pattern:
>>
>> ╭────
>> │ #+BEGIN_NAME PARAMETERS
>> │ CONTENTS
>> │ #+END_NAME
>> ╰────
>
> I'm beginning to wonder if these should have the same syntax as blocks.
> Maybe that's a too fine a distinction visually, but adding a colon would
> disambiguate the greater blocks from the normal ones. In other words
>
> #+BEGIN_CENTER: humdum
> &
> #+END_CENTER:
>
> would be a center block, while
>
> #+BEGIN_CENTER humdum
> &
> #+END_CENTER
>
> would be an export block for the center backend.
I agree. More on that below.
>> 4.2 Blocks
>> ──────────
>>
>> Like [greater blocks], pattern for blocks is:
>>
>> ╭────
>> │ #+BEGIN_NAME DATA
>> │ CONTENTS
>> │ #+END_NAME
>> ╰────
> […]
>> DATA can contain any character but a new line.
>
> I'd keep with PARAMETERS here.
Ok. Just fix it.
>> If NAME is a string matching the name of any export back-end loaded,
>> the block will be an “export block”.
>
> Conversely, blocks that are not having a recognizable name will simply
> insert their content as if the block markers were not there, e.g. it
> seems to treat these as parsed blocks.
You are talking about "special blocks", right? They have a special
purpose. In latex back-end,
#+begin_special
...
#+end_special
becomes
\begin{special}
...
\end{special}
IOW this is an Org feature.
> I don't think this should happen, instead Org should parse this as an
> unknown export backend and drop the content with a warning, not unlike
> a comment.
This would remove special blocks.
> This will be a major sticking point with external parsers: they'd
> otherwise need to know about the Org export backends to when to use the
> content of the block and when not. A portable Org document should be
> able to specify which export backends it expects to be available (and
> maybe what standard backend it is derived from) to elicit the correct
> behaviour.
I agree, as notified above. If we want to separate Org /format/ from
Emacs, we need to separate special blocks from export blocks. The former
cannot be the fallback type when the latter isn't recognized.
In that case, a different syntax for export blocks would be needed.
Maybe the colons you suggested above. I think that something more
visible would be better, though.
>> CONTENTS can contain any character, including new lines. Though it
>> will only contain Org objects if the block is a verse block.
>> Otherwise, contents will not be parsed.
>
> Would it make sense to make a general distinction between parsed and
> non-parsed blocks based on some configuration, even though this would
> produce the same issue as with export backends?
This is inherent from the block type. This mustn't be configurable.
There is no point in parsing a src-block, for example. On the other
hand, if you don't parse (partially) contents of a verse-block, you get
an example-block, and one of them becomes useless.
Then, there are special blocks. It was suggested, a few days ago, that
a parameter could be set in order to tell the parser what to do with
their contents. That's an interesting idea. But it only makes sense if
there is also a way to specify a transformation function on these
contents (otherwise, an export block would be sufficient). Also the same
could be achieved with Babel, the non-parsed data being an example
block, and the transformation function a src-block.
Regards,
--
Nicolas Goaziou
next prev parent reply other threads:[~2013-03-09 23:49 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-07 20:37 [RFC] Org syntax (draft) Nicolas Goaziou
2013-03-07 20:47 ` Carsten Dominik
2013-03-07 22:07 ` Achim Gratz
2013-03-08 10:04 ` Bastien
2013-03-08 10:39 ` was: " Andreas Röhler
2013-03-08 10:46 ` (no subject) Bastien
2013-03-08 10:59 ` Andreas Röhler
2013-03-08 11:05 ` Bastien
2013-03-08 11:18 ` Andreas Röhler
2013-03-08 11:23 ` Bastien
2013-03-08 13:00 ` Andreas Röhler
2013-03-08 13:12 ` Bastien
2013-03-08 15:22 ` Andreas Röhler
2013-03-08 15:40 ` Bastien
2013-03-08 20:39 ` T.F. Torrey
2013-03-08 21:19 ` Nicolas Goaziou
2013-03-08 21:57 ` Suvayu Ali
2013-03-08 22:15 ` interoperability matters " Gregor Zattler
2013-03-09 14:09 ` Bastien
2013-03-10 22:40 ` T.F. Torrey
2013-03-08 13:25 ` [RFC] Org syntax (draft) François Pinard
2013-03-08 15:23 ` Nicolas Richard
2013-03-08 22:06 ` Nicolas Goaziou
2013-03-09 10:52 ` Waldemar Quevedo
2013-03-09 14:23 ` Carsten Dominik
2013-03-09 14:42 ` Nicolas Goaziou
2013-03-09 15:05 ` Carsten Dominik
2013-03-15 20:22 ` Nicolas Goaziou
2013-03-17 18:48 ` Samuel Wales
2013-04-05 17:01 ` Bastien
2013-03-13 14:07 ` Nicolas Richard
2013-03-15 20:39 ` Nicolas Goaziou
2013-03-09 23:16 ` Achim Gratz
2013-03-09 23:49 ` Nicolas Goaziou [this message]
2013-03-10 4:35 ` Jambunathan K
2013-03-10 7:08 ` Nicolas Goaziou
2013-03-10 10:14 ` Bastien
2013-03-10 10:16 ` Bastien
2013-03-10 13:07 ` Achim Gratz
2013-03-10 14:11 ` Bastien
2013-03-10 16:02 ` Achim Gratz
2013-03-10 16:09 ` Jambunathan K
2013-03-10 17:12 ` Achim Gratz
2013-03-10 21:44 ` Jonathan Leech-Pepin
2013-03-10 15:44 ` Jambunathan K
2013-03-14 16:58 ` Eric S Fraga
2013-03-14 18:26 ` Jambunathan K
2013-03-14 18:51 ` David Engster
2013-03-14 19:03 ` [Out-of-Thread] " Jambunathan K
2013-03-14 19:15 ` David Engster
2013-03-14 19:23 ` Jambunathan K
2013-03-14 19:29 ` David Engster
2013-03-14 19:52 ` Jambunathan K
2013-04-09 16:37 ` Bastien
2013-03-17 7:18 ` Achim Gratz
2013-03-17 9:36 ` Sebastien Vauban
-- strict thread matches above, loose matches on Subject: below --
2013-03-12 10:19 orgmode
2013-03-13 15:33 ` Nicolas Goaziou
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=878v5wi163.fsf@gmail.com \
--to=n.goaziou@gmail.com \
--cc=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).