From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thorsten Jolitz Subject: Re: Can `org-element-map' act on secondary-strings? Date: Mon, 08 Jul 2013 18:54:16 +0200 Message-ID: <8738rpq9fr.fsf@gmail.com> References: <87li5jrbx3.fsf@gmail.com> <871u7bfw4x.fsf@gmail.com> <87obada5ck.fsf@gmail.com> <87wqp1ec0b.fsf@gmail.com> <87ip0l9rxu.fsf@gmail.com> <87pputdx5a.fsf@gmail.com> <87ehb99n86.fsf@gmail.com> <87sizpf8jx.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:52959) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UwEhw-000310-6z for emacs-orgmode@gnu.org; Mon, 08 Jul 2013 12:54:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UwEhs-0000LT-6O for emacs-orgmode@gnu.org; Mon, 08 Jul 2013 12:54:36 -0400 Received: from plane.gmane.org ([80.91.229.3]:49717) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UwEhr-0000LF-Vt for emacs-orgmode@gnu.org; Mon, 08 Jul 2013 12:54:32 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UwEho-0001tD-SE for emacs-orgmode@gnu.org; Mon, 08 Jul 2013 18:54:28 +0200 Received: from e178063147.adsl.alicedsl.de ([85.178.63.147]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Jul 2013 18:54:28 +0200 Received: from tjolitz by e178063147.adsl.alicedsl.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 08 Jul 2013 18:54:28 +0200 List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Jambunathan K writes: > Thorsten Jolitz writes: > >> Nicolas Goaziou writes: >> >>> You don't need `org-data' type. The tree root doesn't have any property >>> anyway. >> >> I used that because I wanted the whole parse-tree as return value, but >> no matter what `org-element-map' returns, it changes the parse-tree by >> side-effects anyway, so I can just ignore the return value and use the >> modified parse-tree stored somewhere instead - right? > > I have a hard time trying to imagine what you are trying to do. You > should try to explain to us what you are trying to accomplish. > > Why are you storing a parse-tree? I'm transforming a parse tree for my needs, using `org-element-map', but since this functions returns what it mapped and, as Nicolas pointed out, its kind of fruitless to map top-level 'org-data type (since it has no property list), I store the parse-tree in some global variable that gives me easy access to the whole (modified) parse-tree. But its not really about storing something, thats just for convenience. I can (and do) wrap `org-element-map' into a function that receives a complete parse-tree and returns a complete parse-tree after modifying some parts of it (without storing something). > What does the parse-tree store? its just about a complete parse-tree as produced by `org-element-parse-buffer' transformed into a different syntax in several steps. > Does the buffer of which it is a representation change, when the parse > tree changes. no, the parse-tree is only prepared to be digested by a different programming-language. > How are you trying to "use" the parse tree? Is it meant for one-way > or two-way conversion - i.e., interpretation or exportation. in the end it will be used for two-way conversion, but I'm still working on the "from-elisp-to-..." part (while learning how the org-mode parser and the export framework work). I don't want to talk too much about the project until I know its going to work out. When there is something tangible I will announce it... -- cheers, Thorsten