From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: [PARSER] Why not add properties to type 'org-data'? Date: Thu, 05 Sep 2013 21:14:56 +0200 Message-ID: <87zjrrytan.fsf@gmail.com> References: <87y57be0zv.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:45730) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHf0z-0007kp-GP for emacs-orgmode@gnu.org; Thu, 05 Sep 2013 15:14:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VHf0t-0000kE-Gq for emacs-orgmode@gnu.org; Thu, 05 Sep 2013 15:14:49 -0400 Received: from mail-wi0-x231.google.com ([2a00:1450:400c:c05::231]:50198) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHf0t-0000k2-9P for emacs-orgmode@gnu.org; Thu, 05 Sep 2013 15:14:43 -0400 Received: by mail-wi0-f177.google.com with SMTP id cb5so2254869wib.10 for ; Thu, 05 Sep 2013 12:14:42 -0700 (PDT) In-Reply-To: <87y57be0zv.fsf@gmail.com> (Thorsten Jolitz's message of "Thu, 05 Sep 2013 17:34:12 +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: Thorsten Jolitz Cc: emacs-orgmode@gnu.org 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. Regards, -- Nicolas Goaziou