From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thorsten Jolitz Subject: Re: [PARSER] Why not add properties to type 'org-data'? Date: Thu, 05 Sep 2013 23:24:55 +0200 Message-ID: <87txhzdkrc.fsf@gmail.com> References: <87y57be0zv.fsf@gmail.com> <87zjrrytan.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:39249) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHh3G-0007Zc-E0 for emacs-orgmode@gnu.org; Thu, 05 Sep 2013 17:25:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VHh3A-0003PJ-8b for emacs-orgmode@gnu.org; Thu, 05 Sep 2013 17:25:18 -0400 Received: from plane.gmane.org ([80.91.229.3]:41722) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHh3A-0003PF-1g for emacs-orgmode@gnu.org; Thu, 05 Sep 2013 17:25:12 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VHh34-0004CS-2P for emacs-orgmode@gnu.org; Thu, 05 Sep 2013 23:25:06 +0200 Received: from e178059067.adsl.alicedsl.de ([85.178.59.67]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Sep 2013 23:25:06 +0200 Received: from tjolitz by e178059067.adsl.alicedsl.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Sep 2013 23:25:06 +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 Nicolas Goaziou writes: Hello, > Thorsten Jolitz writes: > >> Wouldn't it make sense to replace >> >> ,---------------------------------------------- >> | (org-data nil (section (:begin 1 :end 52 ...))) >> `---------------------------------------------- >> >> with something like >> >> ,------------------------------------------------------------------------- >> | (org-data (:id-or-name file001 :input-file /my/file.org :author me :date >> | 01-01-2013 :description my planning data) (section (:begin 1 :end 52 >> | ...))) >> `------------------------------------------------------------------------- >> >> ? > > This is way beyond parser's attributions. For example, getting the right > date means that every SETUPFILE keyword should be inspected. INCLUDE > keywords too. And some macros could get expanded in the process. > > Also keep in mind that some keywords, e.g. DESCRIPTION, are defined and > made special at the export framework level (see > `org-export-options-alist'). There are just regular keywords to the > parser. IOW, for the parser, there is no difference between > > #+DESRCIPTION: something > > and > > #+FOO: something > > At one point, I thought about combining parse tree and information > channel, much like what you're suggesting, but in `ox.el'. It would give > something like an "Org closure" wrapping both contents and environment > together. > > But I discarded that idea, as it was very artificial: the minute the > closure was created, it was splitted again so it could get processed. OK, I do like the separation of parse tree and communication channel in the exporter, and I can use the exporter to extract and put the necessary 'org-data' DB object attributes, at the very least the file name or a unique ID. But sometimes, when only the parse-tree is needed, not the exporter framework, it would indeed be useful if that highest level element the others refer to as parent (org-data) would have some kind of unique name/id. What would be the cost of introducing just one single unique attribute like: ,------------------------------------------------------------------------- | (org-data (:input-file /my/file.org) (section (:begin 1 :end 52 ...))) `------------------------------------------------------------------------- or ,------------------------------------------------------------------------- | (org-data (:ID 08AF34b12) (section (:begin 1 :end 52 ...))) `------------------------------------------------------------------------- to make different parse trees distinguishable (and associated to the parsed file)? -- cheers, Thorsten