Programmatically constructing org documents

Programmatically constructing org documents

[Arun Isaac]

[-- Attachment #1: Type: text/plain, Size: 310 bytes --]


What is the "correct" way to programmatically construct org documents?

Should I construct a parse tree, and then use
`org-element-interpret-data' to convert it org syntax?

Or, should I use string and buffer functions (such as `format' and
`insert') to construct org syntax directly?

Thank you,
Arun Isaac.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

Re: Programmatically constructing org documents

[John Kitchin]

I don't know if there is a "correct" way. It might depend on how
sophisticated the document is. I usually use strings and format.
Sometimes that is a pain though, if there is a lot of conditional
formatting. So the question is which is easier for your situation, and I
would say easier is "correct" ;)

Arun Isaac writes:

> What is the "correct" way to programmatically construct org documents?
>
> Should I construct a parse tree, and then use
> `org-element-interpret-data' to convert it org syntax?
>
> Or, should I use string and buffer functions (such as `format' and
> `insert') to construct org syntax directly?
>
> Thank you,
> Arun Isaac.


-- 
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

Re: Programmatically constructing org documents

[Arun Isaac]

> I don't know if there is a "correct" way. It might depend on how
> sophisticated the document is. I usually use strings and format.
> Sometimes that is a pain though, if there is a lot of conditional
> formatting. So the question is which is easier for your situation, and I
> would say easier is "correct" ;)

Fair enough. Sounds good. Thank you.

Re: Programmatically constructing org documents

[John Kitchin]

After some more thought, I am not sure it is possible to setup just a
parse tree for this. It works ok for src blocks, e.g.

#+BEGIN_SRC emacs-lisp
(org-element--interpret-data-1
 '(src-block
   (:language "emacs-lisp" :switches nil :parameters ":results code"  :value "(org-element-context)\n" :post-blank 1 :parent nil))
 nil)
#+END_SRC

#+RESULTS:
: #+BEGIN_SRC emacs-lisp :results code
: (org-element-context)
: #+END_SRC
:

On the other hand, it isn't clear how to use this to make a table.

e.g. this table:

| 5 | 6 |
| 6 | 7 |

was represented as an element like this.

(table
 (:begin 5133 :end 5154 :type org :tblfm nil :contents-begin 5133 :contents-end 5153 :value nil :post-blank 1 :post-affiliated 5133 :parent nil))

There is no data in that representation, just points in the buffer where
the data is. Does anyone know how to do this?

Related to this, I have wanted to be able to have code blocks output
full figures and tables with captions and attributes. I usually do this by building
up strings and using :results org drawer, but it might be nice to build
an element and render it.

I feel like what you really want is this:
http://oremacs.com/2015/01/23/eltex/ for org-mode.



Arun Isaac writes:

>> I don't know if there is a "correct" way. It might depend on how
>> sophisticated the document is. I usually use strings and format.
>> Sometimes that is a pain though, if there is a lot of conditional
>> formatting. So the question is which is easier for your situation, and I
>> would say easier is "correct" ;)
>
> Fair enough. Sounds good. Thank you.


-- 
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

Re: Programmatically constructing org documents

[Charles C. Berry]

On Mon, 27 Jun 2016, John Kitchin wrote:

> After some more thought, I am not sure it is possible to setup just a
> parse tree for this. It works ok for src blocks, e.g.
>
[deleted]

> On the other hand, it isn't clear how to use this to make a table.
>
> e.g. this table:
>
> | 5 | 6 |
> | 6 | 7 |
>
> was represented as an element like this.
>
> (table
> (:begin 5133 :end 5154 :type org :tblfm nil :contents-begin 5133 :contents-end 5153 :value nil :post-blank 1 :post-affiliated 5133 :parent nil))
>
> There is no data in that representation, just points in the buffer where
> the data is. Does anyone know how to do this?


Use (org-element-parse-buffer) to get the table-row and table-cell elements, too.

--8<---------------cut here---------------start------------->8---

| 5 | 6 |
| 6 | 7 |


#+BEGIN_SRC emacs-lisp
   (org-element-map (org-element-parse-buffer) 'table-cell 'cddr)
#+END_SRC

--8<---------------cut here---------------end--------------->8---


HTH,

Chuck

Re: Programmatically constructing org documents

[John Kitchin]

Cool, thanks for the tip.

So, you can build a table like this:

#+BEGIN_SRC emacs-lisp
(org-element--interpret-data-1
 '((table (:caption (((("Some interesting thing."))))) (table-row '()
			 (table-cell '() ("5"))
			 (table-cell '() ("6")))
	  (table-row '()
		     (table-cell '() ("6"))
		     (table-cell '() ("7")))))
 nil)
#+END_SRC

that is sure to be handy one day ;)


Charles C. Berry writes:

> On Mon, 27 Jun 2016, John Kitchin wrote:
>
>> After some more thought, I am not sure it is possible to setup just a
>> parse tree for this. It works ok for src blocks, e.g.
>>
> [deleted]
>
>> On the other hand, it isn't clear how to use this to make a table.
>>
>> e.g. this table:
>>
>> | 5 | 6 |
>> | 6 | 7 |
>>
>> was represented as an element like this.
>>
>> (table
>> (:begin 5133 :end 5154 :type org :tblfm nil :contents-begin 5133 :contents-end 5153 :value nil :post-blank 1 :post-affiliated 5133 :parent nil))
>>
>> There is no data in that representation, just points in the buffer where
>> the data is. Does anyone know how to do this?
>
>
> Use (org-element-parse-buffer) to get the table-row and table-cell elements, too.
>
> --8<---------------cut here---------------start------------->8---
>
> | 5 | 6 |
> | 6 | 7 |
>
>
> #+BEGIN_SRC emacs-lisp
>    (org-element-map (org-element-parse-buffer) 'table-cell 'cddr)
> #+END_SRC
>
> --8<---------------cut here---------------end--------------->8---
>
>
> HTH,
>
> Chuck


-- 
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu

Re: Programmatically constructing org documents

[Samuel W. Flint]

Does something like this do what you're looking for?

https://github.com/tj64/org-dp

HTH,

Sam

-- 
Samuel W. Flint
4096R/266596F4
      (9477 D23E 389E 40C5 2F10  DE19 68E5 318E 2665 96F4)
(λs.s s) λs.s s

Re: Programmatically constructing org documents

[Arun Isaac]

[-- Attachment #1: Type: text/plain, Size: 370 bytes --]


> https://github.com/tj64/org-dp

I've seen org-dp before, but I'm confused about how it is different from
org-element functions like `org-element-interpret-data'.

Does it just add more convenience functions? If so, why not integrate
org-dp into org-mode itself? Surely, convenience functions such as those
provided by org-dp are useful enough to be part of org-mode.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]