From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: emacs-orgmode@gnu.org
Subject: Re: Org-element once again
Date: Wed, 08 Oct 2014 15:31:40 +0800 [thread overview]
Message-ID: <87lhorvwyr.fsf@ericabrahamsen.net> (raw)
In-Reply-To: 8738azrpry.fsf@gmail.com
Thorsten Jolitz <tjolitz@gmail.com> writes:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Marcin Borkowski <mbork@wmi.amu.edu.pl> writes:
>>
>>> Hi list,
>>>
>>> does there exist any place I could find the specs of the org-element
>>> data structure? From what I can see, it is a list whose car is the type
>>> of the element, then a (somewhat mysterious or me) plist follows, and
>>> then the children. Where could I find more info? If the answer is
>>> "read the source, Luke" ;-) , which functions should I start with?
>>>
>>> Best,
>>
>> Have you looked at this page?
>>
>> http://orgmode.org/worg/dev/org-element-api.html
>>
>> That and the pages linked from it seem to cover most of what's going on.
>>
>> The mysterious plist holds all the properties for a given element. Most
>> are generated by the parsing process (eg :contents-begin and
>> :contents-end, see the link above for all the different properties the
>> various elements/objects might get), while headlines will also have
>> their actual property-drawer properties put into the list.
>>
>> The only thing that remains a little opaque to me is the "section"
>> element, which apparently gets wrapped around a heading's subtree. I
>> don't know what it does, but it's never gotten in my way so I haven't
>> worried about it.
>
> in simple terms, the data structure is just:
>
> ,----
> | (element-typ (plist) (section))
> `----
>
> i.e. the plist describes the element itself, the section is its
> content.
>
>
> * TODO Test :@home:
> DEADLINE: <2014-10-09 Do>
> :PROPERTIES:
> :ARCHIVE: foo
> :END:
>
>
> org-element-at-point does not parse the contents of an element, it
> thus simply returns
>
> ,----
> | (element-typ (plist))
> `----
>
> #+NAME: foo
> #+BEGIN_SRC emacs-lisp
>
> (save-excursion
> (outline-previous-heading)
> (org-element-at-point))
> #+END_SRC
>
> # [:results pp]
> #+results:
> : (headline
> : (:raw-value "Test" :begin 1432 :end 2214 :pre-blank 0 :contents-begin 1452 :contents-end 2214 :level 1 :priority nil :tags
> : ("@home")
> : :todo-keyword "TODO" :todo-type todo :post-blank 0 :footnote-section-p nil :archivedp nil :commentedp nil :post-affiliated 1432 :deadline
> : (timestamp
> : (:type active :raw-value "<2014-10-09 Do>" :year-start 2014
> :month-start 10 :day-start 9 :hour-start nil :minute-start nil
> :year-end 2014 :month-end 10 :day-end 9 :hour-end nil :minute-end nil
> :begin 1464 :end 1479 :post-blank 0))
> : :ARCHIVE "foo" :title "Test"))
>
> #+NAME: bar
> #+BEGIN_SRC emacs-lisp :var x=foo
>
> (org-element-interpret-data x)
> #+END_SRC
>
> #+results: bar
> : * TODO Test :@home:
>
>
> so this is (just) the element (headline) as specified by its plist.
>
> You can get the contents e.g. with
>
> #+BEGIN_SRC emacs-lisp :results wrap
> (require 'org-dp-lib)
> (save-excursion
> (outline-previous-heading)
> (org-dp-contents nil t)))
> #+END_SRC
>
> #+results:
> :RESULTS:
> DEADLINE: <2014-10-09 Do>
> :PROPERTIES:
> :ARCHIVE: foo
> :END:
>
> [...]
> :END:
>
> but the default org-element-parse-buffer parses everything (when specified), the
> contents too, so it would give you
>
> ,----
> | (element-typ (plist) (section))
> `----
>
> with section recursively containing other elements with the same
> structure -> a nested list.
Interesting! I didn't realize that all elements came with a section when
you parsed the buffer, thanks for pointing that out.
E
prev parent reply other threads:[~2014-10-08 7:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-07 23:10 Org-element once again Marcin Borkowski
2014-10-08 2:44 ` Eric Abrahamsen
2014-10-08 7:20 ` Thorsten Jolitz
2014-10-08 7:31 ` Eric Abrahamsen [this message]
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=87lhorvwyr.fsf@ericabrahamsen.net \
--to=eric@ericabrahamsen.net \
--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).