From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bastien Subject: Re: [new exporter] adhere org-export-date-timestamp-format? Date: Wed, 09 Jan 2013 19:30:48 +0100 Message-ID: <87vcb6qkdj.fsf@bzg.ath.cx> References: <877gpj3raa.fsf@pank.eu> <87623stdza.fsf@bzg.ath.cx> <87bod2637u.fsf@gmail.com> <8738yeh6ts.fsf@bzg.ath.cx> <87wqvm2x3f.fsf@gmail.com> <87sj6ai8gx.fsf@bzg.ath.cx> <87k3rm2q03.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:46120) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tt0QP-0000LU-LD for emacs-orgmode@gnu.org; Wed, 09 Jan 2013 13:30:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tt0QN-0008Oa-LI for emacs-orgmode@gnu.org; Wed, 09 Jan 2013 13:30:53 -0500 Received: from mail-we0-f169.google.com ([74.125.82.169]:45219) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tt0QN-0008OL-F7 for emacs-orgmode@gnu.org; Wed, 09 Jan 2013 13:30:51 -0500 Received: by mail-we0-f169.google.com with SMTP id t49so1238046wey.0 for ; Wed, 09 Jan 2013 10:30:48 -0800 (PST) In-Reply-To: <87k3rm2q03.fsf@gmail.com> (Nicolas Goaziou's message of "Wed, 09 Jan 2013 19:03:08 +0100") 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: Nicolas Goaziou Cc: emacs-orgmode@gnu.org, Rasmus Hi Nicolas, Nicolas Goaziou writes: > Before I start coding it, I wonder if functions related to timestamp > objects, that is `org-export-timestamp-has-time-p', > `org-export-format-timestamp', `org-export-split-timestamp-range' and > `org-export-translate-timestamp' shouldn't be moved from org-export.el > to org.el. After all, there are not only useful in an export context. > > What do you think about it? I agree they are general and should be move out of org-export.el. Note that one of my plan for 8.[01] is to put org.el on diet so that it loads more quickly and for more basic stuff. So maybe there will be org-plan.el at some point for org-schedule, org-deadline and anything related to planning. Ideally, Org would *just* be outline reloaded (with orgtble and all editing facilities), while other features would have their own library. So maybe those functions will end up outside of org.el one day... but I'd say it's okay to have them in org.el for now. Thanks, -- Bastien