* Programmatically constructing org documents
@ 2016-06-24 14:16 Arun Isaac
2016-06-26 15:12 ` John Kitchin
0 siblings, 1 reply; 8+ messages in thread
From: Arun Isaac @ 2016-06-24 14:16 UTC (permalink / raw)
To: emacs-orgmode@gnu.org
[-- 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 --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Programmatically constructing org documents
2016-06-24 14:16 Programmatically constructing org documents Arun Isaac
@ 2016-06-26 15:12 ` John Kitchin
2016-06-26 19:50 ` Arun Isaac
0 siblings, 1 reply; 8+ messages in thread
From: John Kitchin @ 2016-06-26 15:12 UTC (permalink / raw)
To: Arun Isaac; +Cc: emacs-orgmode@gnu.org
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Programmatically constructing org documents
2016-06-26 15:12 ` John Kitchin
@ 2016-06-26 19:50 ` Arun Isaac
2016-06-27 12:12 ` John Kitchin
0 siblings, 1 reply; 8+ messages in thread
From: Arun Isaac @ 2016-06-26 19:50 UTC (permalink / raw)
To: John Kitchin; +Cc: emacs-orgmode@gnu.org
> 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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Programmatically constructing org documents
2016-06-26 19:50 ` Arun Isaac
@ 2016-06-27 12:12 ` John Kitchin
2016-06-27 16:13 ` Charles C. Berry
2016-06-27 19:19 ` Samuel W. Flint
0 siblings, 2 replies; 8+ messages in thread
From: John Kitchin @ 2016-06-27 12:12 UTC (permalink / raw)
To: Arun Isaac; +Cc: emacs-orgmode@gnu.org
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Programmatically constructing org documents
2016-06-27 12:12 ` John Kitchin
@ 2016-06-27 16:13 ` Charles C. Berry
2016-06-27 17:52 ` John Kitchin
2016-06-27 19:19 ` Samuel W. Flint
1 sibling, 1 reply; 8+ messages in thread
From: Charles C. Berry @ 2016-06-27 16:13 UTC (permalink / raw)
To: John Kitchin; +Cc: Arun Isaac, emacs-orgmode@gnu.org
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Programmatically constructing org documents
2016-06-27 16:13 ` Charles C. Berry
@ 2016-06-27 17:52 ` John Kitchin
0 siblings, 0 replies; 8+ messages in thread
From: John Kitchin @ 2016-06-27 17:52 UTC (permalink / raw)
To: Charles C. Berry; +Cc: Arun Isaac, emacs-orgmode@gnu.org
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Programmatically constructing org documents
2016-06-27 12:12 ` John Kitchin
2016-06-27 16:13 ` Charles C. Berry
@ 2016-06-27 19:19 ` Samuel W. Flint
2016-06-28 3:15 ` Arun Isaac
1 sibling, 1 reply; 8+ messages in thread
From: Samuel W. Flint @ 2016-06-27 19:19 UTC (permalink / raw)
To: John Kitchin; +Cc: emacs-orgmode@gnu.org
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Programmatically constructing org documents
2016-06-27 19:19 ` Samuel W. Flint
@ 2016-06-28 3:15 ` Arun Isaac
0 siblings, 0 replies; 8+ messages in thread
From: Arun Isaac @ 2016-06-28 3:15 UTC (permalink / raw)
To: Samuel W. Flint; +Cc: emacs-orgmode@gnu.org
[-- 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 --]
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2016-06-28 3:15 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-06-24 14:16 Programmatically constructing org documents Arun Isaac
2016-06-26 15:12 ` John Kitchin
2016-06-26 19:50 ` Arun Isaac
2016-06-27 12:12 ` John Kitchin
2016-06-27 16:13 ` Charles C. Berry
2016-06-27 17:52 ` John Kitchin
2016-06-27 19:19 ` Samuel W. Flint
2016-06-28 3:15 ` Arun Isaac
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).