From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thorsten Jolitz Newsgroups: gmane.emacs.help Subject: Problems with Emacs print syntax Date: Tue, 10 Sep 2013 09:12:32 +0200 Message-ID: <877gepp2u7.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1378797192 14059 80.91.229.3 (10 Sep 2013 07:13:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 10 Sep 2013 07:13:12 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Sep 10 09:13:15 2013 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VJI8R-0000Xi-22 for geh-help-gnu-emacs@m.gmane.org; Tue, 10 Sep 2013 09:13:15 +0200 Original-Received: from localhost ([::1]:56093 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VJI8Q-0003ys-It for geh-help-gnu-emacs@m.gmane.org; Tue, 10 Sep 2013 03:13:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37997) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VJI8B-0003xC-Pn for help-gnu-emacs@gnu.org; Tue, 10 Sep 2013 03:13:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VJI85-0003aI-KL for help-gnu-emacs@gnu.org; Tue, 10 Sep 2013 03:12:59 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:40581) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VJI85-0003Yb-Ea for help-gnu-emacs@gnu.org; Tue, 10 Sep 2013 03:12:53 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VJI81-0008Cj-Md for help-gnu-emacs@gnu.org; Tue, 10 Sep 2013 09:12:49 +0200 Original-Received: from e178188006.adsl.alicedsl.de ([85.178.188.6]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Sep 2013 09:12:49 +0200 Original-Received: from tjolitz by e178188006.adsl.alicedsl.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 10 Sep 2013 09:12:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 93 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: e178188006.adsl.alicedsl.de User-Agent: Gnus/5.130002 (Ma Gnus v0.2) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:QRiQ7M5cVRfBMdaOIKVnZN039wI= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:93315 Archived-At: 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