[Exporter] How to save 'info' plist for later use?

[Exporter] How to save 'info' plist for later use?

[Thorsten Jolitz]

Hi List, 

how do I get my hands on the 'info' plist (i.e. the communication-channel)
when I try to export data that is (only an isolated) part of a parse-tree? 

Say that originally a whole buffer was parsed, thus the full tree and
options info was available at that point. But then parts of the
resulting parse-tree are extracted with org-element-map and are exported
separately as data later on.

In that case, I don't know how to pass the original 'info' plist to the
export function, so export results are not complete due to the missing
context information.

Here is a minimal example:

With file minimal.org

#+begin_src org
* A
B
#+end_src

I call

#+begin_src emacs-lisp
(setq parse-tree
        (with-current-buffer
            (find-file-noselect
             "/path/to/minimal.org")
          (org-element-parse-buffer)))

(let ((elem (org-element-map parse-tree 'headline 'identity nil t)))
  (insert (format "\n\n%s\n\n" elem))
  ;; nil instead of info as 3rd parameter
  (insert (org-export-data-with-backend  elem 'html nil))) 
#+end_src

and get (note the incomplete IDs in the html)

#+begin_quote
(headline (:raw-value A :begin 1 :end 7 :pre-blank 0 :hiddenp
nil :contents-begin 5 :contents-end 7 :level 1 :priority
nil :tags nil :todo-keyword nil :todo-type nil :post-blank
0 :footnote-section-p nil :archivedp nil :commentedp nil :quotedp
nil :CATEGORY nil :title (A) :parent (org-data nil
#0)) (section (:begin 5 :end 7 :contents-begin 5 :contents-end
7 :post-blank 0 :parent #0) (paragraph (:begin 5 :end
7 :contents-begin 5 :contents-end 7 :post-blank
0 :post-affiliated 5 :parent #1) B )))

<nil id="outline-container-sec-" class="outline-2">
<h2 id="sec-">A</h2>
<div class="outline-text-2" id="text-">
<p>
B
</p>
</div>
</nil>
#+end_quote

How could I get my hands on the 'info' plist during the buffer parsing
and save it for later use in calls like

#+begin_src emacs-lisp
(org-export-data-with-backend  elem 'html info)
#+end_src

?

-- 
cheers,
Thorsten

Re: [Exporter] How to save 'info' plist for later use?

[Robert Klein]

Hi Thorsten,


I'm currently playing around with retrieving options, e.g. functions like:

#+begin_src elisp
(defun org-find-export-option (file option-name &optional backend)
  "Find the OPTION of FILE."
   (let* ((org-inhibit-startup t)
         (visiting (find-buffer-visiting file))
         (buffer (or visiting (find-file-noselect file)))
         option)
    (with-current-buffer buffer
      (org-mode)
      (setq option
            (plist-get (org-export-get-environment backend) option-name)))
    (unless visiting (kill-buffer buffer))
    option))



(defun org-get-comma-separated-options-as-list (file option)
  "Fetch OPTION from FILE as a list."

  (split-string
   (replace-regexp-in-string ", *" ","
                             (org-find-export-option file option 'blog))
   "[,\n]"
   t))
#+end_src



org-get-comma-separated-options-as-list description:

If you got options in MYFILE inthe form of
#+OPTION_NAME: a, b, two words, something else
#+OPTION_NAME: and, comma, at end,
#+OPTION_NAME: for, example

call
    (org-get-comma-separated-options-as-list MYFILE :option-name)

(:option-name is the KEYWORD in the options alist, cf. ox.el)

you will get them now as
'( "a" "b" "two words" "something else" "and" "comma" "at end" "for"
"example").
"





The code is some copy and pasting of a current project, but should give
you some ideas.


org-find-export-option is also a slightly changed copy of
ox-publish.el's org-publish-find-title.



Best regards
Robert



On 07/10/2013 12:56 PM, Thorsten Jolitz wrote:
> 
> Hi List, 
> 
> how do I get my hands on the 'info' plist (i.e. the communication-channel)
> when I try to export data that is (only an isolated) part of a parse-tree? 
> 
> Say that originally a whole buffer was parsed, thus the full tree and
> options info was available at that point. But then parts of the
> resulting parse-tree are extracted with org-element-map and are exported
> separately as data later on.
> 
> In that case, I don't know how to pass the original 'info' plist to the
> export function, so export results are not complete due to the missing
> context information.
> 
> Here is a minimal example:
> 
> With file minimal.org
> 
> #+begin_src org
> * A
> B
> #+end_src
> 
> I call
> 
> #+begin_src emacs-lisp
> (setq parse-tree
>         (with-current-buffer
>             (find-file-noselect
>              "/path/to/minimal.org")
>           (org-element-parse-buffer)))
> 
> (let ((elem (org-element-map parse-tree 'headline 'identity nil t)))
>   (insert (format "\n\n%s\n\n" elem))
>   ;; nil instead of info as 3rd parameter
>   (insert (org-export-data-with-backend  elem 'html nil))) 
> #+end_src
> 
> and get (note the incomplete IDs in the html)
> 
> #+begin_quote
> (headline (:raw-value A :begin 1 :end 7 :pre-blank 0 :hiddenp
> nil :contents-begin 5 :contents-end 7 :level 1 :priority
> nil :tags nil :todo-keyword nil :todo-type nil :post-blank
> 0 :footnote-section-p nil :archivedp nil :commentedp nil :quotedp
> nil :CATEGORY nil :title (A) :parent (org-data nil
> #0)) (section (:begin 5 :end 7 :contents-begin 5 :contents-end
> 7 :post-blank 0 :parent #0) (paragraph (:begin 5 :end
> 7 :contents-begin 5 :contents-end 7 :post-blank
> 0 :post-affiliated 5 :parent #1) B )))
> 
> <nil id="outline-container-sec-" class="outline-2">
> <h2 id="sec-">A</h2>
> <div class="outline-text-2" id="text-">
> <p>
> B
> </p>
> </div>
> </nil>
> #+end_quote
> 
> How could I get my hands on the 'info' plist during the buffer parsing
> and save it for later use in calls like
> 
> #+begin_src emacs-lisp
> (org-export-data-with-backend  elem 'html info)
> #+end_src
> 
> ?
> 


-- 
Robert Klein - Max Planck-Institut für Polymerforschung
Ackermannweg 10
55128 Mainz

Re: [Exporter] How to save 'info' plist for later use?

[Thorsten Jolitz]

Thorsten Jolitz <tjolitz@gmail.com> writes:

PS

> How could I get my hands on the 'info' plist during the buffer parsing
> and save it for later use in calls like

As far as I understand it, the 'info' plist is actually dynamically
created and modified in various stages of the export process. 

So what I really mean is probably: 

How could I get my hands on an 'info-like' plist that contains all the
tree and options information available at the moment a buffer is parsed
with `org-element-parse-buffer' - and save it for later use?

-- 
cheers,
Thorsten

Re: [Exporter] How to save 'info' plist for later use?

[Nick Dokos]

Thorsten Jolitz <tjolitz@gmail.com> writes:

> Thorsten Jolitz <tjolitz@gmail.com> writes:
>
> PS
>
>> How could I get my hands on the 'info' plist during the buffer parsing
>> and save it for later use in calls like
>
> As far as I understand it, the 'info' plist is actually dynamically
> created and modified in various stages of the export process. 
>
> So what I really mean is probably: 
>
> How could I get my hands on an 'info-like' plist that contains all the
> tree and options information available at the moment a buffer is parsed
> with `org-element-parse-buffer' - and save it for later use?

edebug-defun org-element-parse-buffer, do whatever is necessary for it
to get called, and when it stops, evaluate it with ``e'' or switch to *scratch*
and save it in your own variable:

(setq thorsten-info info)

-- 
Nick

Re: [Exporter] How to save 'info' plist for later use?

[Thorsten Jolitz]

Robert Klein <kleinrob@mpip-mainz.mpg.de> writes:

Hi Robert,

> I'm currently playing around with retrieving options, e.g. functions like:

> #+begin_src elisp
> (defun org-find-export-option (file option-name &optional backend) ...

thanks, that brought me on the right track, I was searching for
functions containing '-info-', but '-options-' would have been the
better search term:

,------------------------------------------------------------------------
| org-export--get-global-options         org-export--get-inbuffer-options
| org-export--get-subtree-options        org-export-backend-options
| org-export-get-all-options
`------------------------------------------------------------------------

So during the buffer parsing I can collect relevant options and build an
'info-like' plist with them and the complete parse-tree for later use.

-- 
cheers,
Thorsten

Re: [Exporter] How to save 'info' plist for later use?

[Thorsten Jolitz]

Nick Dokos <ndokos@gmail.com> writes:

> Thorsten Jolitz <tjolitz@gmail.com> writes:
>
>> Thorsten Jolitz <tjolitz@gmail.com> writes:
>>
>> PS
>>
>>> How could I get my hands on the 'info' plist during the buffer parsing
>>> and save it for later use in calls like
>>
>> As far as I understand it, the 'info' plist is actually dynamically
>> created and modified in various stages of the export process. 
>>
>> So what I really mean is probably: 
>>
>> How could I get my hands on an 'info-like' plist that contains all the
>> tree and options information available at the moment a buffer is parsed
>> with `org-element-parse-buffer' - and save it for later use?
>
> edebug-defun org-element-parse-buffer, do whatever is necessary for it
>to get called, and when it stops, evaluate it with ``e'' or switch to
>*scratch* and save it in your own variable:
>
> (setq thorsten-info info)

Thats a nice trick, but I'm afraid that the 'info' plist is not created
during the parsing but rather during the export. When I want something
similar after just parsing, I might have to create it myself. 

PS
and how would you use this trick in a program?

-- 
cheers,
Thorsten

Re: [Exporter] How to save 'info' plist for later use?

[Jambunathan K]

Add a filter or a translator.  One of the arguments to that filter is
the plist you are looking for.  Work back from there and you will get
the right APIs to use.

The snippet below from ox-odt.el should be a good starting point for
further exploration.  The translators do fairly *non-trivial*
transformation on the "lispy" parse-tree before triggering off the
actual export.  There you will see the APIs for element translation.

  :filters-alist '((:filter-parse-tree
		    . (org-odt--translate-latex-fragments
		       org-odt--translate-description-lists ; Dummy symbol
		       org-odt--translate-list-tables)))

Re: [Exporter] How to save 'info' plist for later use?

[Thorsten Jolitz]

Jambunathan K <kjambunathan@gmail.com> writes:

> Add a filter or a translator.  One of the arguments to that filter is
> the plist you are looking for.  Work back from there and you will get
> the right APIs to use.
>
> The snippet below from ox-odt.el should be a good starting point for
> further exploration.  The translators do fairly *non-trivial*
> transformation on the "lispy" parse-tree before triggering off the
> actual export.  There you will see the APIs for element translation.
>
>   :filters-alist '((:filter-parse-tree
> 		    . (org-odt--translate-latex-fragments
> 		       org-odt--translate-description-lists ; Dummy symbol
> 		       org-odt--translate-list-tables)))

Thats indeed close to what I need and a useful example, thanks. 

-- 
cheers,
Thorsten

Re: [Exporter] How to save 'info' plist for later use?

[Eric Abrahamsen]

Thorsten Jolitz <tjolitz@gmail.com> writes:

> Nick Dokos <ndokos@gmail.com> writes:
>
>> Thorsten Jolitz <tjolitz@gmail.com> writes:
>>
>>> Thorsten Jolitz <tjolitz@gmail.com> writes:
>>>
>>> PS
>>>
>>>> How could I get my hands on the 'info' plist during the buffer parsing
>>>> and save it for later use in calls like
>>>
>>> As far as I understand it, the 'info' plist is actually dynamically
>>> created and modified in various stages of the export process. 
>>>
>>> So what I really mean is probably: 
>>>
>>> How could I get my hands on an 'info-like' plist that contains all the
>>> tree and options information available at the moment a buffer is parsed
>>> with `org-element-parse-buffer' - and save it for later use?
>>
>> edebug-defun org-element-parse-buffer, do whatever is necessary for it
>>to get called, and when it stops, evaluate it with ``e'' or switch to
>>*scratch* and save it in your own variable:
>>
>> (setq thorsten-info info)
>
> Thats a nice trick, but I'm afraid that the 'info' plist is not created
> during the parsing but rather during the export. When I want something
> similar after just parsing, I might have to create it myself. 
>
> PS
> and how would you use this trick in a program?

If you look in the `org-export-as' function, you can see the part where
the info plist is built, looks like most of it is done by
org-export--get-buffer-attributes.

Re: [Exporter] How to save 'info' plist for later use?

[Eric Abrahamsen]

Thorsten Jolitz <tjolitz@gmail.com> writes:

> Robert Klein <kleinrob@mpip-mainz.mpg.de> writes:
>
> Hi Robert,
>
>> I'm currently playing around with retrieving options, e.g. functions like:
>
>> #+begin_src elisp
>> (defun org-find-export-option (file option-name &optional backend) ...
>
> thanks, that brought me on the right track, I was searching for
> functions containing '-info-', but '-options-' would have been the
> better search term:
>
> ,------------------------------------------------------------------------
> | org-export--get-global-options         org-export--get-inbuffer-options
> | org-export--get-subtree-options        org-export-backend-options
> | org-export-get-all-options
> `------------------------------------------------------------------------
>
> So during the buffer parsing I can collect relevant options and build an
> 'info-like' plist with them and the complete parse-tree for later use.

Oops, I answered before I saw this...

Re: [Exporter] How to save 'info' plist for later use?

[Thorsten Jolitz]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Thorsten Jolitz <tjolitz@gmail.com> writes:
>
>> Nick Dokos <ndokos@gmail.com> writes:
>>
>>> Thorsten Jolitz <tjolitz@gmail.com> writes:
>>>
>>>> Thorsten Jolitz <tjolitz@gmail.com> writes:
>>>>
>>>> PS
>>>>
>>>>> How could I get my hands on the 'info' plist during the buffer parsing
>>>>> and save it for later use in calls like
>>>>
>>>> As far as I understand it, the 'info' plist is actually dynamically
>>>> created and modified in various stages of the export process. 
>>>>
>>>> So what I really mean is probably: 
>>>>
>>>> How could I get my hands on an 'info-like' plist that contains all the
>>>> tree and options information available at the moment a buffer is parsed
>>>> with `org-element-parse-buffer' - and save it for later use?
>>>
>>> edebug-defun org-element-parse-buffer, do whatever is necessary for it
>>>to get called, and when it stops, evaluate it with ``e'' or switch to
>>>*scratch* and save it in your own variable:
>>>
>>> (setq thorsten-info info)
>>
>> Thats a nice trick, but I'm afraid that the 'info' plist is not created
>> during the parsing but rather during the export. When I want something
>> similar after just parsing, I might have to create it myself. 
>>
>> PS
>> and how would you use this trick in a program?
>
> If you look in the `org-export-as' function, you can see the part where
> the info plist is built, looks like most of it is done by
> org-export--get-buffer-attributes.

Thanks for the tip, sometimes its obvious that some functionality is
already implemented, but not so obvious whats the name attached to it.

Looking in the source-code is of course the best way to find out, but I
thought I would have access to all function-names anyway with 

,----------------------
| C-h f org-export- TAB
`----------------------

until I figured out that defining some autoloads and actually loading
the whole library are two different things, and that I will find all
functions that way only after doing an explicit 'M-x load-library' or
after actually using it ... ;)

-- 
cheers,
Thorsten

Re: [Exporter] How to save 'info' plist for later use?

[Jambunathan K]

Thorsten Jolitz <tjolitz@gmail.com> writes:

> Looking in the source-code is of course the best way to find out, but I
> thought I would have access to all function-names anyway with 
>
> ,----------------------
> | C-h f org-export- TAB
> `----------------------
>
> until I figured out that defining some autoloads and actually loading
> the whole library are two different things, and that I will find all
> functions that way only after doing an explicit 'M-x load-library' or
> after actually using it ... ;)


There is an outline struture to the way source code is organized.

    (add-hook 'emacs-lisp-mode-hook 'outline-minor-mode)

    (add-hook 'outline-minor-mode-hook
      (lambda ()
        (define-key outline-minor-mode-map [(control tab)] 'org-cycle)
        ;; (define-key outline-minor-mode-map [(shift tab)] 'org-global-cycle)
        (define-key outline-minor-mode-map [backtab] 'org-global-cycle)
        ))

Now doing

    M-x find-library RET ox.el RET

    S-TAB (one or more times)

will give you a give quick overview of all the function names.

----------------------------------------------------------------

Also there is always this:

   C-1 C-x $

which can be expected to give a quick overview any source file.

Just snap out with:

  C-x $

----------------------------------------------------------------

Or you can build a TAGS file (ctags/etags) and you can find all commands
that match a regexp.

----------------------------------------------------------------