headers
Nicolas Goaziou | 21 Nov 2011 19:50
Picon

[ANN] Org Elements in contrib

Hello,

I've added org-element.el in contrib directory. It is a complete parser
and interpreter for Org syntax.

While it was written to be extensible, it is also an attempt to
normalize current syntax and provide guidance for its evolution.

Org syntax can be divided into three categories: "Greater elements",
"Elements" and "Objects".

An object can be defined anywhere on a line. It may span over more than
a line but never contains a blank one. Objects belong to the following
types: `emphasis', `entity', `export-snippet', `footnote-reference',
`inline-babel-call', `inline-src-block', `latex-fragment', `line-break',
`link', `macro', `radio-target', `statistics-cookie', `subscript',
`superscript', `target', `time-stamp' and `verbatim'.

An element always starts and ends at the beginning of a line. The only
element's type containing objects is called a `paragraph'. Other types
are: `comment', `comment-block', `example-block', `export-block',
`fixed-width', `horizontal-rule', `keyword', `latex-environment',
`babel-call', `property-drawer', `quote-section', `src-block', `table'
and `verse-block'.

Elements containing paragraphs are called greater elements. Concerned
types are: `center-block', `drawer', `dynamic-block',
`footnote-definition', `headline', `inlinetask', `item', `plain-list',
`quote-block' and `special-block'.
(Continue reading)

Permalink | Reply |
headers
Martyn Jago | 21 Nov 2011 23:02
Gravatar

Re: [ANN] Org Elements in contrib

Nicolas Goaziou <n.goaziou <at> gmail.com> writes:
Hi Nicolas

> Hello,
>
>
> I've added org-element.el in contrib directory. It is a complete parser
> and interpreter for Org syntax.
>
> While it was written to be extensible, it is also an attempt to
> normalize current syntax and provide guidance for its evolution.
>
> Org syntax can be divided into three categories: "Greater elements",
> "Elements" and "Objects".
>
> An object can be defined anywhere on a line. It may span over more than
> a line but never contains a blank one. Objects belong to the following
> types: `emphasis', `entity', `export-snippet', `footnote-reference',
> `inline-babel-call', `inline-src-block', `latex-fragment', `line-break',
> `link', `macro', `radio-target', `statistics-cookie', `subscript',
> `superscript', `target', `time-stamp' and `verbatim'.
>
> An element always starts and ends at the beginning of a line. The only
> element's type containing objects is called a `paragraph'. Other types
> are: `comment', `comment-block', `example-block', `export-block',
> `fixed-width', `horizontal-rule', `keyword', `latex-environment',
> `babel-call', `property-drawer', `quote-section', `src-block', `table'
> and `verse-block'.
>
> Elements containing paragraphs are called greater elements. Concerned
(Continue reading)

Permalink | Reply |
headers
Eric Abrahamsen | 22 Nov 2011 06:17

Re: [ANN] Org Elements in contrib

On Tue, Nov 22 2011, Nicolas Goaziou wrote:

> Hello,
>
>
> I've added org-element.el in contrib directory. It is a complete parser
> and interpreter for Org syntax.

This looks great! Is the eventual idea to use this library for other
basic org functionality? It seems ideal for replacing the guts of things
like `org-scan-tags' and family.

--

-- 
GNU Emacs 24.0.91.1 (i686-pc-linux-gnu, GTK+ Version 2.24.6)
 of 2011-11-07 on pellet
Org-mode version 7.7 (release_7.7.578.ge3ec9)
Permalink | Reply |
headers
Brian Wightman | 22 Nov 2011 15:02

Re: [ANN] Org Elements in contrib

On Mon, Nov 21, 2011 at 12:50 PM, Nicolas Goaziou <n.goaziou <at> gmail.com> wrote:
> I've added org-element.el in contrib directory. It is a complete parser
> and interpreter for Org syntax.
>
> While it was written to be extensible, it is also an attempt to
> normalize current syntax and provide guidance for its evolution.

This is also a good thing (IMO) from the viewpoint of being able to
provide external (non-org-mode) parsers for org-mode files.  If
org-element is the canonical definition of org syntax (not semantics,
just syntax), all other parsers must adhere to this or they are in
error.

A slight evolution of this would be to have this definition defined in
the tests, and have org-element, or any other parser, adhere to those
tests.  Defining a canon for org-mode syntax is, in any form, a big
step forward.

Brian
Permalink | Reply |
headers
Thomas S. Dye | 22 Nov 2011 17:00
Gravatar

Re: [ANN] Org Elements in contrib

Aloha Nicolas,

This looks brilliant.  The interactive functions seem to know their way
around my various org-mode files.  Looking forward to the generic
exporter and the LaTeX back-end.

All the best,
Tom

Nicolas Goaziou <n.goaziou <at> gmail.com> writes:

> Hello,
>
>
> I've added org-element.el in contrib directory. It is a complete parser
> and interpreter for Org syntax.
>
> While it was written to be extensible, it is also an attempt to
> normalize current syntax and provide guidance for its evolution.
>
> Org syntax can be divided into three categories: "Greater elements",
> "Elements" and "Objects".
>
> An object can be defined anywhere on a line. It may span over more than
> a line but never contains a blank one. Objects belong to the following
> types: `emphasis', `entity', `export-snippet', `footnote-reference',
> `inline-babel-call', `inline-src-block', `latex-fragment', `line-break',
> `link', `macro', `radio-target', `statistics-cookie', `subscript',
> `superscript', `target', `time-stamp' and `verbatim'.
>
(Continue reading)

Permalink | Reply |
headers
Wes Hardaker | 23 Nov 2011 21:12
Picon

Re: [ANN] Org Elements in contrib

>>>>> On Tue, 22 Nov 2011 06:00:49 -1000, tsd <at> tsdye.com (Thomas S. Dye) said:

TSD> This looks brilliant.  The interactive functions seem to know their way
TSD> around my various org-mode files.  Looking forward to the generic
TSD> exporter and the LaTeX back-end.

Most specifically, the hardest part of writing the org-export-generic
functionality was the parser.  When I started on it, it very quickly
showed that a generic parser with an API was needed (but I didn't have
the time to do that).  This sounds like a perfect replacement for the
guts of the org-export-generic parser.
--

-- 
Wes Hardaker                                     
My Pictures:  http://capturedonearth.com/
My Thoughts:  http://pontifications.hardakers.net/
Permalink | Reply |
headers
Michael Brand | 10 Jun 2012 18:40
Picon

Re: [ANN] Org Elements in contrib

Hi Nicolas

On Mon, Nov 21, 2011 at 7:50 PM, Nicolas Goaziou <n.goaziou <at> gmail.com> wrote:
> I've added org-element.el in contrib directory. It is a complete parser
> and interpreter for Org syntax.
>
> [...]
>
> the following code will parse the buffer, interpret the parsed
> tree, and create a canonical copy of it (no indentation, lowercased
> blocks, standard keywords):
>
> #+begin_src org
> (let ((out (org-element-interpret-data (org-element-parse-buffer))))
>  (switch-to-buffer (get-buffer-create "*Bijectivep*"))
>  (erase-buffer)
>  (insert out)
>  (goto-char (point-min))
>  (org-mode))
> #+end_src
>
> [...]
>
> Feedback is welcome.

Good to mention is also this code to show the pretty print formatted
lisp object representation of the current Org buffer:

#+BEGIN_SRC emacs-lisp
  (let ((out (org-element-parse-buffer)))
(Continue reading)

Permalink | Reply |
headers
Nicolas Goaziou | 12 Jun 2012 14:32
Picon

Re: [ANN] Org Elements in contrib

Hello,

Michael Brand <michael.ch.brand <at> gmail.com> writes:

> Not sure if the following should be supported by
> org-element-interpret-data:
>
> #+BEGIN_SRC org
>   ,variable declaration in some programming languages:
>   ,- Perl :: the variable declaration can be implicit
>   ,- C ::
>   ,  #+BEGIN_SRC C
>   ,    time_t variable_name;
>   ,  #+END_SRC
> #+END_SRC

This bug should be fixed now. Thank you for reporting it.

Regards,

--

-- 
Nicolas Goaziou
Permalink | Reply |
headers
Michael Brand | 12 Jun 2012 16:14
Picon

Re: [ANN] Org Elements in contrib

Hi Nicolas

On Tue, Jun 12, 2012 at 2:32 PM, Nicolas Goaziou <n.goaziou <at> gmail.com> wrote:
> This bug should be fixed now.

I confirm that it is fixed. And as I see from your commit: Thanks to
your modular and therefore stable design it is fixed also for other
cases that I didn't test before with table or list as the only body
element. And the regression tests in general I appreciate a lot too.

Michael
Permalink | Reply |

Gmane