From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bastien Subject: Re: New exporter and dates in tables Date: Thu, 11 Apr 2013 17:49:03 +0200 Message-ID: <8738uxrrtc.fsf@bzg.ath.cx> References: <87fvz1opiz.fsf@norang.ca> <8761zxwlvn.fsf@gmail.com> <87bo9pntym.fsf@norang.ca> <0604BF00-1FE8-4EAA-A346-C125A5127CAD@gmail.com> <877gkcvm3n.fsf@gmail.com> <173ADFE7-A1FB-4ECB-A78A-C99662A8030F@gmail.com> <87fvyysghk.fsf@gmail.com> <87bo9mh6ex.fsf@bzg.ath.cx> <87d2u1s3wf.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([208.118.235.92]:38224) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UQJpY-0003qx-7F for emacs-orgmode@gnu.org; Thu, 11 Apr 2013 11:54:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UQJpX-0005yP-2K for emacs-orgmode@gnu.org; Thu, 11 Apr 2013 11:54:32 -0400 Received: from mail-we0-x22e.google.com ([2a00:1450:400c:c03::22e]:42368) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UQJpW-0005y8-SS for emacs-orgmode@gnu.org; Thu, 11 Apr 2013 11:54:30 -0400 Received: by mail-we0-f174.google.com with SMTP id u12so1347827wey.5 for ; Thu, 11 Apr 2013 08:54:29 -0700 (PDT) In-Reply-To: <87d2u1s3wf.fsf@gmail.com> (Nicolas Goaziou's message of "Thu, 11 Apr 2013 13:28:00 +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: Nicolas Goaziou Cc: Bernt Hansen , emacs-orgmode@gnu.org, Carsten Dominik Hello, Nicolas Goaziou writes: > Thinking more about it, I think I need to make some more exceptions > anyway. For example timestamps in clock lines and in planning info > shouldn't react to `org-export-with-timestamps' (it would be silly to > have `org-export-with-planning' set to t and still see nothing because > `org-export-with-timestamps' is nil). Indeed :) Thinking again about Bernt's use-case and Carsten's feedback, I suggest making rules for planning instead of exceptions for time-stamps. - planning information is - SCHEDULED: - DEADLINE: - CLOSED: - one or more time-stamps (active or inactive) alone on a line - a non-planning time-stamp is any time-stamp that does not fall into the categories above, i.e. if it is inlined in an element (usually a paragraph or a table). The inactive/active time-stamp in a table is handled. And so is another corner case that we did not discussed yet: people using active time-stamps right below a headline, with the expectation that this time-stamp will bring the entry up in the agenda -- such time-stamp is now considered a time-stamp while it is really some planning info. I guess this is cleaner than creating exceptions. What about it? -- Bastien