help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Problems with Emacs print syntax


From: Thorsten Jolitz
Subject: Problems with Emacs print syntax
Date: Tue, 10 Sep 2013 09:12:32 +0200
User-agent: Gnus/5.130002 (Ma Gnus v0.2) Emacs/24.3 (gnu/linux)

Hi List, 

this is a question about the org-element parse-tree, but its actually
about reading 'unreadable' Emacs print syntax, so I ask it here too (in
a slightly different formulation).

How do I get the printed representation of an org-file parse-tree that can be
reverted to the original org-file with `'org-element-interpret-data'?

Elisp manual says:

,-------------------------------------------------------------------------
| Reading and printing are more or less inverse operations: [...]
| 
| However, these two operations are not precisely inverse to each other.
| There are three kinds of exceptions:
| 
|     Printing can produce text that cannot be read. For example, buffers,
|     windows, frames, subprocesses and markers print as text that starts
|     with ‘#’; if you try to read this text, you get an error. There is
|     no way to read those data types. [...]
`-------------------------------------------------------------------------

E.g. given file tmp.org:

,-------------------
| #+options: toc:nil
| * A
| B
`-------------------

#+begin_src emacs-lisp
  (with-current-buffer "tmp.org"
  (org-element-interpret-data (org-element-parse-buffer)))
#+end_src

yields what is expected:

,--------------------
| "#+OPTIONS: toc:nil
| * A
| B
| "
`--------------------

but, e.g., this 

#+begin_src emacs-lisp
  (with-current-buffer "tmp.org"
  (print (org-element-parse-buffer)))
#+end_src

yields:

#+begin_src emacs-lisp
  (org-data nil (section (:begin 1 :end 20 :contents-begin
  1 :contents-end 20 :post-blank 0 :parent
  #0) (keyword (:key "OPTIONS" :value "toc:nil" :begin 1 :end
  20 :post-blank 0 :post-affiliated 1 :parent
  #1))) (headline (:raw-value "A" :begin 20 :end 26 :pre-blank
  0 :hiddenp nil :contents-begin 24 :contents-end 26 :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" 0
  1 (:parent #1))) :parent #0) (section (:begin 24 :end
  26 :contents-begin 24 :contents-end 26 :post-blank 0 :parent
  #1) (paragraph (:begin 24 :end 26 :contents-begin
  24 :contents-end 26 :post-blank 0 :post-affiliated 24 :parent #2)
  #("B" 0 2 (:parent #3))))))
#+end_src

what can't be used with `org-element-interpret-data' directly, but can't
be read first with `read-from-string' or so either because of unreadble
parts like this:

,---------------------------------------------
| :title (#("A" 0 1 (:parent #1))) :parent #0)
`---------------------------------------------

I think it would be great if one could produce a 'readable' printed
representation of such a parse-tree programmatically, read it as Lisp
object, and then interpret that Lisp object with
`org-element-interpret-data' to produce the specified textual Org
element (or Org file). 

How could one achieve that given that Org-mode parser employs
circular lists and strings are stored with text-properties?

-- 
cheers,
Thorsten





reply via email to

[Prev in Thread] Current Thread [Next in Thread]