emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
* New exporter and dates in tables
@ 2013-04-08  0:05 Bernt Hansen
  2013-04-08  2:18 ` Mike McLean
  2013-04-08  6:57 ` Nicolas Goaziou
  0 siblings, 2 replies; 31+ messages in thread
From: Bernt Hansen @ 2013-04-08  0:05 UTC (permalink / raw)
  To: Nicolas Goaziou; +Cc: emacs-orgmode

Hi Nicolas,

I just noticed that the new exporter does not export inactive timestamps
in table columns.  This is now controlled by the option <:t

I think this is a change from the old exporter (but I'm not sure it's
really wrong).

I have subtrees with inactive timestamps in the text indicating when
something occurred.  I normally don't want to export these.  But I think
any table data that includes inactive timestamps should be an exception
to this ... otherwise you get output tables with blank cells where the
meaningful timestamp data would be.  Exporting part of a data table
doesn't really make a lot of sense.

For now I need to delete the inactive timestamps in my running text and
enable export of inactive timestamps to get the same result I did with
the old exporter -- but I lose some of my meta data about when tasks
were created in this case.

ie.

| Date             | Amount     |  Item |
|------------------+------------+-------|
| [2013-04-04 Thu] | Lunch      | 12.50 |
| [2013-04-06 Sat] | Parking    |  6.00 |
| [2013-04-07 Sun] | Train Fair | 14.30 |

exports with no data in column 1 when I have

:PROPERTIES:
:EXPORT_OPTIONS: toc:nil <:nil
:END:

Thanks,
Bernt

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: New exporter and dates in tables
  2013-04-08  0:05 New exporter and dates in tables Bernt Hansen
@ 2013-04-08  2:18 ` Mike McLean
  2013-04-08  6:57 ` Nicolas Goaziou
  1 sibling, 0 replies; 31+ messages in thread
From: Mike McLean @ 2013-04-08  2:18 UTC (permalink / raw)
  To: Bernt Hansen; +Cc: emacs-orgmode, Nicolas Goaziou


On Apr 7, 2013, at 8:05 PM, Bernt Hansen <bernt@norang.ca> wrote:

> Hi Nicolas,
> 
> I just noticed that the new exporter does not export inactive timestamps
> in table columns.  This is now controlled by the option <:t
> 
> I think this is a change from the old exporter (but I'm not sure it's
> really wrong).

Timing is everything. I just noticed the same thing today. I also don't know if it is “wrong” or not, but it is different than the old exporter.

In my case I used org-collector to generate the tables, so my workaround was an ugly hack around the property selector in my dynamic block line.

#+begin_example
#+begin: <other org collector options> :cols ( (replace-regexp-in-string " .*\]" "" (replace-regexp-in-string "^\\[" "" (format "%s" ops-meeting-date))) …)
#+end_example

Where ~ops-meeting-date~ is a property on some of my headlines that in turn is an inactive timestamp.

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: New exporter and dates in tables
  2013-04-08  0:05 New exporter and dates in tables Bernt Hansen
  2013-04-08  2:18 ` Mike McLean
@ 2013-04-08  6:57 ` Nicolas Goaziou
  2013-04-08 11:27   ` Bernt Hansen
  1 sibling, 1 reply; 31+ messages in thread
From: Nicolas Goaziou @ 2013-04-08  6:57 UTC (permalink / raw)
  To: Bernt Hansen; +Cc: emacs-orgmode

Hello,

Bernt Hansen <bernt@norang.ca> writes:

> I have subtrees with inactive timestamps in the text indicating when
> something occurred.  I normally don't want to export these.  But I think
> any table data that includes inactive timestamps should be an exception
> to this ... otherwise you get output tables with blank cells where the
> meaningful timestamp data would be.

I understand.

So what exactly should be this exception? Should export ignore <:nil
option in a whole table, or only when a table cell contains a single
timestamp? IOW, how would it behaves in the following table:

  | [2013-04-04 Thu] | Lunch at [2013-04-04 Thu] ] |

when `org-export-with-timestamps' is either nil or `active'?

Also, this must be documented. Exceptions tend to accumulate a lot and
make the global behaviour unpredictable. Would you mind providing an
explanation to this, which would fit in `org-export-with-timestamps'
docstring?


Regards,

-- 
Nicolas Goaziou

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: New exporter and dates in tables
  2013-04-08  6:57 ` Nicolas Goaziou
@ 2013-04-08 11:27   ` Bernt Hansen
  2013-04-08 11:33     ` Carsten Dominik
  0 siblings, 1 reply; 31+ messages in thread
From: Bernt Hansen @ 2013-04-08 11:27 UTC (permalink / raw)
  To: Nicolas Goaziou; +Cc: emacs-orgmode

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Bernt Hansen <bernt@norang.ca> writes:
>
>> I have subtrees with inactive timestamps in the text indicating when
>> something occurred.  I normally don't want to export these.  But I think
>> any table data that includes inactive timestamps should be an exception
>> to this ... otherwise you get output tables with blank cells where the
>> meaningful timestamp data would be.
>
> I understand.
>
> So what exactly should be this exception? Should export ignore <:nil
> option in a whole table, or only when a table cell contains a single
> timestamp? IOW, how would it behaves in the following table:
>
>   | [2013-04-04 Thu] | Lunch at [2013-04-04 Thu] ] |
>
> when `org-export-with-timestamps' is either nil or `active'?

I think keeping it simple is best.  If there is an inactive timestamp in
a table then it should be exported (I consider everything in a table as
data).

>
> Also, this must be documented. Exceptions tend to accumulate a lot and
> make the global behaviour unpredictable. Would you mind providing an
> explanation to this, which would fit in `org-export-with-timestamps'
> docstring?
>

Sure I can do that.  I will follow up with a patch in this thread this
week after the behaviour has been determined.

Regards,
Bernt

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: New exporter and dates in tables
  2013-04-08 11:27   ` Bernt Hansen
@ 2013-04-08 11:33     ` Carsten Dominik
  2013-04-08 19:49       ` Nicolas Goaziou
  0 siblings, 1 reply; 31+ messages in thread
From: Carsten Dominik @ 2013-04-08 11:33 UTC (permalink / raw)
  To: Bernt Hansen; +Cc: emacs-orgmode, Nicolas Goaziou


On 8 apr. 2013, at 13:27, Bernt Hansen <bernt@norang.ca> wrote:

> Nicolas Goaziou <n.goaziou@gmail.com> writes:
> 
>> Bernt Hansen <bernt@norang.ca> writes:
>> 
>>> I have subtrees with inactive timestamps in the text indicating when
>>> something occurred.  I normally don't want to export these.  But I think
>>> any table data that includes inactive timestamps should be an exception
>>> to this ... otherwise you get output tables with blank cells where the
>>> meaningful timestamp data would be.
>> 
>> I understand.
>> 
>> So what exactly should be this exception? Should export ignore <:nil
>> option in a whole table, or only when a table cell contains a single
>> timestamp? IOW, how would it behaves in the following table:
>> 
>>  | [2013-04-04 Thu] | Lunch at [2013-04-04 Thu] ] |
>> 
>> when `org-export-with-timestamps' is either nil or `active'?
> 
> I think keeping it simple is best.  If there is an inactive timestamp in
> a table then it should be exported (I consider everything in a table as
> data).


I think this is the right way to look at this.

- Carsten

> 
>> 
>> Also, this must be documented. Exceptions tend to accumulate a lot and
>> make the global behaviour unpredictable. Would you mind providing an
>> explanation to this, which would fit in `org-export-with-timestamps'
>> docstring?
>> 
> 
> Sure I can do that.  I will follow up with a patch in this thread this
> week after the behaviour has been determined.
> 
> Regards,
> Bernt
> 

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: New exporter and dates in tables
  2013-04-08 11:33     ` Carsten Dominik
@ 2013-04-08 19:49       ` Nicolas Goaziou
  2013-04-09 13:06         ` Carsten Dominik
  0 siblings, 1 reply; 31+ messages in thread
From: Nicolas Goaziou @ 2013-04-08 19:49 UTC (permalink / raw)
  To: Carsten Dominik; +Cc: Bernt Hansen, emacs-orgmode

Hello,

Carsten Dominik <carsten.dominik@gmail.com> writes:

> On 8 apr. 2013, at 13:27, Bernt Hansen <bernt@norang.ca> wrote:
>
>> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>> 
>>> Bernt Hansen <bernt@norang.ca> writes:
>>> 
>>>> I have subtrees with inactive timestamps in the text indicating when
>>>> something occurred.  I normally don't want to export these.  But I think
>>>> any table data that includes inactive timestamps should be an exception
>>>> to this ... otherwise you get output tables with blank cells where the
>>>> meaningful timestamp data would be.
>>> 
>>> I understand.
>>> 
>>> So what exactly should be this exception? Should export ignore <:nil
>>> option in a whole table, or only when a table cell contains a single
>>> timestamp? IOW, how would it behaves in the following table:
>>> 
>>>  | [2013-04-04 Thu] | Lunch at [2013-04-04 Thu] ] |
>>> 
>>> when `org-export-with-timestamps' is either nil or `active'?
>> 
>> I think keeping it simple is best.  If there is an inactive timestamp in
>> a table then it should be exported (I consider everything in a table as
>> data).
>
>
> I think this is the right way to look at this.

I still find it surprising that <:nil will remove the timestamp in:

  Lunch at [2013-04-04 Thu]

but not in

  | Lunch at [2013-04-04 Thu] |

I suppose I'll eventually get it.

Anyway, there's still another thing to ponder. Since everything in
a table is data, what happens with "tex:nil" (LaTeX snippets)? Should
this option also be ignored within a table? If not, how can we explain
the difference with "<:nil"?


Regards,

-- 
Nicolas Goaziou

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: New exporter and dates in tables
  2013-04-08 19:49       ` Nicolas Goaziou
@ 2013-04-09 13:06         ` Carsten Dominik
  2013-04-10 12:43           ` Nicolas Goaziou
  0 siblings, 1 reply; 31+ messages in thread
From: Carsten Dominik @ 2013-04-09 13:06 UTC (permalink / raw)
  To: Nicolas Goaziou; +Cc: Bernt Hansen, emacs-orgmode


On 8 apr. 2013, at 21:49, Nicolas Goaziou <n.goaziou@gmail.com> wrote:

> Hello,
> 
> Carsten Dominik <carsten.dominik@gmail.com> writes:
> 
>> On 8 apr. 2013, at 13:27, Bernt Hansen <bernt@norang.ca> wrote:
>> 
>>> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>>> 
>>>> Bernt Hansen <bernt@norang.ca> writes:
>>>> 
>>>>> I have subtrees with inactive timestamps in the text indicating when
>>>>> something occurred.  I normally don't want to export these.  But I think
>>>>> any table data that includes inactive timestamps should be an exception
>>>>> to this ... otherwise you get output tables with blank cells where the
>>>>> meaningful timestamp data would be.
>>>> 
>>>> I understand.
>>>> 
>>>> So what exactly should be this exception? Should export ignore <:nil
>>>> option in a whole table, or only when a table cell contains a single
>>>> timestamp? IOW, how would it behaves in the following table:
>>>> 
>>>> | [2013-04-04 Thu] | Lunch at [2013-04-04 Thu] ] |
>>>> 
>>>> when `org-export-with-timestamps' is either nil or `active'?
>>> 
>>> I think keeping it simple is best.  If there is an inactive timestamp in
>>> a table then it should be exported (I consider everything in a table as
>>> data).
>> 
>> 
>> I think this is the right way to look at this.
> 
> I still find it surprising that <:nil will remove the timestamp in:
> 
>  Lunch at [2013-04-04 Thu]
> 
> but not in
> 
>  | Lunch at [2013-04-04 Thu] |
> 
> I suppose I'll eventually get it.

Yes, I agree that it is hard to nail the exact reasons. The
reasoning for me goes like this:

Some people throw in time stamps often while they work, just
as a little label, indicating that they were working on this
at a specific date, or that the entry was created on a specific
date.  Many people I know have a hook that throws in such a
time stamp in each new entry created.  This creates a lot of
clutter when you print it, which is why you can turn off
export of timestamps.

That option was not meant for a contextual line like your
first example.  If you use the time stamps in this way, you
probably will not turn off timestamp export at all, you
will just leave it on.  If you mix both ways of using
time stamps - well, too bad.

Tabular data is different because you certainly wanted
that data in the table, so removing it will be confusing.

> Anyway, there's still another thing to ponder. Since everything in
> a table is data, what happens with "tex:nil" (LaTeX snippets)? Should
> this option also be ignored within a table? If not, how can we explain
> the difference with "<:nil"?

Tex macros are different.  This is an internal way of
inserting special characters, and that syntax may get into
your way in some specific projects.  Just like the fact
that _ creates a subscript.  If you have to write text
with lots of _ but you never mean a subscript, this can
be really annoying.  So you can turn off subscripts as you
can turn off interpretation of tex macros, as a convenience
if the syntax gets in your way.  Then it should be turned
off anywhere, table or not.

Regards

- Carsten


> 
> 
> Regards,
> 
> -- 
> Nicolas Goaziou

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: New exporter and dates in tables
  2013-04-09 13:06         ` Carsten Dominik
@ 2013-04-10 12:43           ` Nicolas Goaziou
  2013-04-10 13:12             ` Carsten Dominik
  2013-04-10 13:16             ` Bastien
  0 siblings, 2 replies; 31+ messages in thread
From: Nicolas Goaziou @ 2013-04-10 12:43 UTC (permalink / raw)
  To: Carsten Dominik; +Cc: Bernt Hansen, emacs-orgmode

[-- Attachment #1: Type: text/plain, Size: 1715 bytes --]

Hello,

Carsten Dominik <carsten.dominik@gmail.com> writes:

> Some people throw in time stamps often while they work, just
> as a little label, indicating that they were working on this
> at a specific date, or that the entry was created on a specific
> date.  Many people I know have a hook that throws in such a
> time stamp in each new entry created.  This creates a lot of
> clutter when you print it, which is why you can turn off
> export of timestamps.
>
> That option was not meant for a contextual line like your
> first example.  If you use the time stamps in this way, you
> probably will not turn off timestamp export at all, you
> will just leave it on.  If you mix both ways of using
> time stamps - well, too bad.
>
> Tabular data is different because you certainly wanted
> that data in the table, so removing it will be confusing.
>
>> Anyway, there's still another thing to ponder. Since everything in
>> a table is data, what happens with "tex:nil" (LaTeX snippets)? Should
>> this option also be ignored within a table? If not, how can we explain
>> the difference with "<:nil"?
>
> Tex macros are different.  This is an internal way of
> inserting special characters, and that syntax may get into
> your way in some specific projects.  Just like the fact
> that _ creates a subscript.  If you have to write text
> with lots of _ but you never mean a subscript, this can
> be really annoying.  So you can turn off subscripts as you
> can turn off interpretation of tex macros, as a convenience
> if the syntax gets in your way.  Then it should be turned
> off anywhere, table or not.

Fair enough. The following patch should do as decided in this thread.

WDYT?


Regards,

-- 
Nicolas Goaziou

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-ox-Don-t-skip-timestamps-within-tables.patch --]
[-- Type: text/x-patch, Size: 3027 bytes --]

From a2b4ef1ad24cbd816491122d0e969fecc6739377 Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou <n.goaziou@gmail.com>
Date: Wed, 10 Apr 2013 14:38:13 +0200
Subject: [PATCH] ox: Don't skip timestamps within tables

* lisp/ox.el (org-export--skip-p): Never skip a timestamp within
  a table.
(org-export-with-timestamps): Update docstring accordingly.
* testing/lisp/test-ox.el: Add test.
---
 lisp/ox.el              | 32 +++++++++++++++++++-------------
 testing/lisp/test-ox.el |  7 ++++++-
 2 files changed, 25 insertions(+), 14 deletions(-)

diff --git a/lisp/ox.el b/lisp/ox.el
index 7f33755..a9667d9 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -721,6 +721,9 @@ It can be set to `active', `inactive', t or nil, in order to
 export, respectively, only active timestamps, only inactive ones,
 all of them or none.
 
+This variable has no effect on timestamps within tables, which
+will always be exported.
+
 This option can also be set with the OPTIONS keyword, e.g.
 \"<:nil\"."
   :group 'org-export-general
@@ -2013,19 +2016,22 @@ a tree with a select tag."
 	  (not (org-export-get-previous-element blob options))))
     (table-row (org-export-table-row-is-special-p blob options))
     (timestamp
-     (case (plist-get options :with-timestamps)
-       ;; No timestamp allowed.
-       ('nil t)
-       ;; Only active timestamps allowed and the current one isn't
-       ;; active.
-       (active
-	(not (memq (org-element-property :type blob)
-		   '(active active-range))))
-       ;; Only inactive timestamps allowed and the current one isn't
-       ;; inactive.
-       (inactive
-	(not (memq (org-element-property :type blob)
-		   '(inactive inactive-range))))))))
+     ;; Timestamps in tables are not affected by `:with-timestamps'.
+     (unless (eq (org-element-type (org-export-get-parent-element blob))
+		 'table-row)
+       (case (plist-get options :with-timestamps)
+	 ;; No timestamp allowed.
+	 ('nil t)
+	 ;; Only active timestamps allowed and the current one isn't
+	 ;; active.
+	 (active
+	  (not (memq (org-element-property :type blob)
+		     '(active active-range))))
+	 ;; Only inactive timestamps allowed and the current one isn't
+	 ;; inactive.
+	 (inactive
+	  (not (memq (org-element-property :type blob)
+		     '(inactive inactive-range)))))))))
 
 \f
 ;;; The Transcoder
diff --git a/testing/lisp/test-ox.el b/testing/lisp/test-ox.el
index 6203f8b..0900037 100644
--- a/testing/lisp/test-ox.el
+++ b/testing/lisp/test-ox.el
@@ -408,7 +408,12 @@ Paragraph"
 	      "<2012-04-29 sun. 10:45>\n"))
       (should
        (equal (org-export-as 'test nil nil nil '(:with-timestamps inactive))
-	      "[2012-04-29 sun. 10:45]\n")))))
+	      "[2012-04-29 sun. 10:45]\n"))))
+  (should
+   (equal "| [2012-03-29 Thu] |\n"
+	  (org-test-with-temp-text "| [2012-03-29 Thu] |"
+	    (org-test-with-backend test
+	      (org-export-as 'test nil nil nil '(:with-timestamps nil)))))))
 
 (ert-deftest test-org-export/comment-tree ()
   "Test if export process ignores commented trees."
-- 
1.8.2.1


^ permalink raw reply related	[flat|nested] 31+ messages in thread

* Re: New exporter and dates in tables
  2013-04-10 12:43           ` Nicolas Goaziou
@ 2013-04-10 13:12             ` Carsten Dominik
  2013-04-10 13:16             ` Bastien
  1 sibling, 0 replies; 31+ messages in thread
From: Carsten Dominik @ 2013-04-10 13:12 UTC (permalink / raw)
  To: Nicolas Goaziou; +Cc: Bernt Hansen, emacs-orgmode

This looks good to me - with my limited understanding of the exporter lingo.

Thanks!

- Carsten

On 10 apr. 2013, at 14:43, Nicolas Goaziou <n.goaziou@gmail.com> wrote:

> Hello,
> 
> Carsten Dominik <carsten.dominik@gmail.com> writes:
> 
>> Some people throw in time stamps often while they work, just
>> as a little label, indicating that they were working on this
>> at a specific date, or that the entry was created on a specific
>> date.  Many people I know have a hook that throws in such a
>> time stamp in each new entry created.  This creates a lot of
>> clutter when you print it, which is why you can turn off
>> export of timestamps.
>> 
>> That option was not meant for a contextual line like your
>> first example.  If you use the time stamps in this way, you
>> probably will not turn off timestamp export at all, you
>> will just leave it on.  If you mix both ways of using
>> time stamps - well, too bad.
>> 
>> Tabular data is different because you certainly wanted
>> that data in the table, so removing it will be confusing.
>> 
>>> Anyway, there's still another thing to ponder. Since everything in
>>> a table is data, what happens with "tex:nil" (LaTeX snippets)? Should
>>> this option also be ignored within a table? If not, how can we explain
>>> the difference with "<:nil"?
>> 
>> Tex macros are different.  This is an internal way of
>> inserting special characters, and that syntax may get into
>> your way in some specific projects.  Just like the fact
>> that _ creates a subscript.  If you have to write text
>> with lots of _ but you never mean a subscript, this can
>> be really annoying.  So you can turn off subscripts as you
>> can turn off interpretation of tex macros, as a convenience
>> if the syntax gets in your way.  Then it should be turned
>> off anywhere, table or not.
> 
> Fair enough. The following patch should do as decided in this thread.
> 
> WDYT?
> 
> 
> Regards,
> 
> -- 
> Nicolas Goaziou
> From a2b4ef1ad24cbd816491122d0e969fecc6739377 Mon Sep 17 00:00:00 2001
> From: Nicolas Goaziou <n.goaziou@gmail.com>
> Date: Wed, 10 Apr 2013 14:38:13 +0200
> Subject: [PATCH] ox: Don't skip timestamps within tables
> 
> * lisp/ox.el (org-export--skip-p): Never skip a timestamp within
>  a table.
> (org-export-with-timestamps): Update docstring accordingly.
> * testing/lisp/test-ox.el: Add test.
> ---
> lisp/ox.el              | 32 +++++++++++++++++++-------------
> testing/lisp/test-ox.el |  7 ++++++-
> 2 files changed, 25 insertions(+), 14 deletions(-)
> 
> diff --git a/lisp/ox.el b/lisp/ox.el
> index 7f33755..a9667d9 100644
> --- a/lisp/ox.el
> +++ b/lisp/ox.el
> @@ -721,6 +721,9 @@ It can be set to `active', `inactive', t or nil, in order to
> export, respectively, only active timestamps, only inactive ones,
> all of them or none.
> 
> +This variable has no effect on timestamps within tables, which
> +will always be exported.
> +
> This option can also be set with the OPTIONS keyword, e.g.
> \"<:nil\"."
>   :group 'org-export-general
> @@ -2013,19 +2016,22 @@ a tree with a select tag."
> 	  (not (org-export-get-previous-element blob options))))
>     (table-row (org-export-table-row-is-special-p blob options))
>     (timestamp
> -     (case (plist-get options :with-timestamps)
> -       ;; No timestamp allowed.
> -       ('nil t)
> -       ;; Only active timestamps allowed and the current one isn't
> -       ;; active.
> -       (active
> -	(not (memq (org-element-property :type blob)
> -		   '(active active-range))))
> -       ;; Only inactive timestamps allowed and the current one isn't
> -       ;; inactive.
> -       (inactive
> -	(not (memq (org-element-property :type blob)
> -		   '(inactive inactive-range))))))))
> +     ;; Timestamps in tables are not affected by `:with-timestamps'.
> +     (unless (eq (org-element-type (org-export-get-parent-element blob))
> +		 'table-row)
> +       (case (plist-get options :with-timestamps)
> +	 ;; No timestamp allowed.
> +	 ('nil t)
> +	 ;; Only active timestamps allowed and the current one isn't
> +	 ;; active.
> +	 (active
> +	  (not (memq (org-element-property :type blob)
> +		     '(active active-range))))
> +	 ;; Only inactive timestamps allowed and the current one isn't
> +	 ;; inactive.
> +	 (inactive
> +	  (not (memq (org-element-property :type blob)
> +		     '(inactive inactive-range)))))))))
> 
> 
> ;;; The Transcoder
> diff --git a/testing/lisp/test-ox.el b/testing/lisp/test-ox.el
> index 6203f8b..0900037 100644
> --- a/testing/lisp/test-ox.el
> +++ b/testing/lisp/test-ox.el
> @@ -408,7 +408,12 @@ Paragraph"
> 	      "<2012-04-29 sun. 10:45>\n"))
>       (should
>        (equal (org-export-as 'test nil nil nil '(:with-timestamps inactive))
> -	      "[2012-04-29 sun. 10:45]\n")))))
> +	      "[2012-04-29 sun. 10:45]\n"))))
> +  (should
> +   (equal "| [2012-03-29 Thu] |\n"
> +	  (org-test-with-temp-text "| [2012-03-29 Thu] |"
> +	    (org-test-with-backend test
> +	      (org-export-as 'test nil nil nil '(:with-timestamps nil)))))))
> 
> (ert-deftest test-org-export/comment-tree ()
>   "Test if export process ignores commented trees."
> -- 
> 1.8.2.1
> 

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: New exporter and dates in tables
  2013-04-10 12:43           ` Nicolas Goaziou
  2013-04-10 13:12             ` Carsten Dominik
@ 2013-04-10 13:16             ` Bastien
  2013-04-11 11:28               ` Nicolas Goaziou
  1 sibling, 1 reply; 31+ messages in thread
From: Bastien @ 2013-04-10 13:16 UTC (permalink / raw)
  To: Nicolas Goaziou; +Cc: Bernt Hansen, emacs-orgmode, Carsten Dominik

Hi all,

Note that Org 8.0-pre comes with a new export option
`org-export-with-planning' which handles the export of
SCHEDULED / DEADLINE / CLOSED time-stamps.

This used to be the job of org-export-with-timestamps.

I guess many people who used (setq org-export-with-timestamps nil)
now want (setq org-export-with-planning nil) and which works well
with (setq org-export-with-timestamps 'inactive).

So I'm wondering: would the setup above spare us with this exception?

I know people sometimes throw inactive time-stamps, but those small
indications would better fit in a commented line.

WDYT?

Best,

-- 
 Bastien

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: New exporter and dates in tables
  2013-04-10 13:16             ` Bastien
@ 2013-04-11 11:28               ` Nicolas Goaziou
  2013-04-11 15:49                 ` Bastien
  0 siblings, 1 reply; 31+ messages in thread
From: Nicolas Goaziou @ 2013-04-11 11:28 UTC (permalink / raw)
  To: Bastien; +Cc: Bernt Hansen, emacs-orgmode, Carsten Dominik

Hello,

Bastien <bzg@gnu.org> writes:

> Note that Org 8.0-pre comes with a new export option
> `org-export-with-planning' which handles the export of
> SCHEDULED / DEADLINE / CLOSED time-stamps.
>
> This used to be the job of org-export-with-timestamps.
>
> I guess many people who used (setq org-export-with-timestamps nil)
> now want (setq org-export-with-planning nil) and which works well
> with (setq org-export-with-timestamps 'inactive).
>
> So I'm wondering: would the setup above spare us with this exception?
>
> I know people sometimes throw inactive time-stamps, but those small
> indications would better fit in a commented line.
>
> WDYT?

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).

After all, this exception may not be that exceptional.


Regards,

-- 
Nicolas Goaziou

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: New exporter and dates in tables
  2013-04-11 11:28               ` Nicolas Goaziou
@ 2013-04-11 15:49                 ` Bastien
  2013-04-13 10:54                   ` Nicolas Goaziou
  0 siblings, 1 reply; 31+ messages in thread
From: Bastien @ 2013-04-11 15:49 UTC (permalink / raw)
  To: Nicolas Goaziou; +Cc: Bernt Hansen, emacs-orgmode, Carsten Dominik

Hello,

Nicolas Goaziou <n.goaziou@gmail.com> 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: <time-stamp>
  - DEADLINE: <time-stamp>
  - CLOSED: <time-stamp>
  - 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

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: New exporter and dates in tables
  2013-04-11 15:49                 ` Bastien
@ 2013-04-13 10:54                   ` Nicolas Goaziou
  2013-04-13 14:02                     ` Bastien
  0 siblings, 1 reply; 31+ messages in thread
From: Nicolas Goaziou @ 2013-04-13 10:54 UTC (permalink / raw)
  To: Bastien; +Cc: Bernt Hansen, emacs-orgmode, Carsten Dominik

Hello,

Bastien <bzg@gnu.org> writes:

> Nicolas Goaziou <n.goaziou@gmail.com> 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: <time-stamp>
>   - DEADLINE: <time-stamp>
>   - CLOSED: <time-stamp>
>   - 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).

SCHEDULED and friends define a property in the associated headline.
Generic timestamps don't (excepted for the first one, but it's arbitrary
and the parser ignores it anyway).

Also, there can be as many active timestamps in a section, but there can
be only one planning info element.

Therefore, I don't think they belong to the same category. We ought to
treat them differently, like we do at the moment.

> 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.

This is obviously some planning info, but not a "planning-info" element.
Any active timestamp is a planning info by the way. The "planning-info"
term just defines the line with SCHEDULED, DEADLINE, CLOSED keyword. It
may be silly, be a name had to be chosen.

Anyway, I don't think it's a corner case.

> I guess this is cleaner than creating exceptions.
>
> What about it?

I'd rather create the aforementioned exceptions (in tables but more
importantly in planning info and clocks): it is important to distinguish
"planning-info" from a mere timestamp. We can change the name if it's
confusing, though.

Is that OK with you?


Regards,

-- 
Nicolas Goaziou

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: New exporter and dates in tables
  2013-04-13 10:54                   ` Nicolas Goaziou
@ 2013-04-13 14:02                     ` Bastien
  2013-04-13 17:33                       ` Nicolas Goaziou
  0 siblings, 1 reply; 31+ messages in thread
From: Bastien @ 2013-04-13 14:02 UTC (permalink / raw)
  To: Nicolas Goaziou; +Cc: Bernt Hansen, emacs-orgmode, Carsten Dominik

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Is that OK with you?

I still resist this idea.

I would find it both cleaner and more useful for users to extend
`org-export-with-timestamps' with three choices:

  'inactive-not-standalone
    'active-not-standalone
           'not-standalone

When set to 'not-standalone, it means export time-stamps except
"standone time-stamps", i.e. those who are alone on a line.  That's
the set-up most users will want after t, it fits the habits that
Bernt has been describing, and it's useful for users who wants to
get rid of the planning-like active time-stamp right below the
headline.

Also, it's easier to explain users how to set this up (through
the docstring) than to explain why time-stamps are not removed in
tables with (setq org-export-with-timestamps nil).

-- 
 Bastien

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: New exporter and dates in tables
  2013-04-13 14:02                     ` Bastien
@ 2013-04-13 17:33                       ` Nicolas Goaziou
  2013-04-13 21:07                         ` Sebastien Vauban
  2013-04-14  8:58                         ` Bastien
  0 siblings, 2 replies; 31+ messages in thread
From: Nicolas Goaziou @ 2013-04-13 17:33 UTC (permalink / raw)
  To: Bastien; +Cc: Bernt Hansen, emacs-orgmode, Carsten Dominik

Bastien <bzg@gnu.org> writes:

> I would find it both cleaner and more useful for users to extend
> `org-export-with-timestamps' with three choices:
>
>   'inactive-not-standalone
>     'active-not-standalone
>            'not-standalone

This is a different idea. The change would happen at the exporter level,
not at parser's.

> When set to 'not-standalone, it means export time-stamps except
> "standone time-stamps", i.e. those who are alone on a line.

Well, parsing is not line based, and "a timestamp alone on a line"
doesn't mean much. Though, "a timestamp alone in a paragraph" is much
easier to translate. IOW:

  <2013-04-13 Sat>
  is not a standalone timestamp (use M-q).

but,

  <2013-04-13 Sat>

  is a standalone timestamp.

> That's the set-up most users will want after t, it fits the habits
> that Bernt has been describing, and it's useful for users who wants to
> get rid of the planning-like active time-stamp right below the
> headline.
>
> Also, it's easier to explain users how to set this up (through
> the docstring) than to explain why time-stamps are not removed in
> tables with (setq org-export-with-timestamps nil).

If we agree to the "alone in a paragraph" part, I can implement it.

But we still need exceptions for clocks and timestamps (i.e., ignore
`org-export-with-timestamps' value when `org-export-with-planning' or
`org-export-with-clocks' is non-nil).


Regards,

-- 
Nicolas Goaziou

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: New exporter and dates in tables
  2013-04-13 17:33                       ` Nicolas Goaziou
@ 2013-04-13 21:07                         ` Sebastien Vauban
  2013-04-14  9:10                           ` Bastien
  2013-04-14  8:58                         ` Bastien
  1 sibling, 1 reply; 31+ messages in thread
From: Sebastien Vauban @ 2013-04-13 21:07 UTC (permalink / raw)
  To: emacs-orgmode-mXXj517/zsQ

Hello,

Nicolas Goaziou wrote:
> Bastien <bzg-mXXj517/zsQ@public.gmane.org> writes:
>
>> I would find it both cleaner and more useful for users to extend
>> `org-export-with-timestamps' with three choices:
>>
>>   'inactive-not-standalone
>>     'active-not-standalone
>>            'not-standalone
>
> This is a different idea. The change would happen at the exporter level,
> not at parser's.
>
>> When set to 'not-standalone, it means export time-stamps except
>> "standone time-stamps", i.e. those who are alone on a line.
>
> Well, parsing is not line based, and "a timestamp alone on a line"
> doesn't mean much. Though, "a timestamp alone in a paragraph" is much
> easier to translate. IOW:
>
>   <2013-04-13 Sat>
>   is not a standalone timestamp (use M-q).
>
> but,
>
>   <2013-04-13 Sat>
>
>   is a standalone timestamp.

Wouldn't it be a good moment to introduce

  APPT: <2013-04-13 Sat>

or maybe better named

  EVENT: <2013-04-13 Sat>

for things that only apply for today?

Best regards,
  Seb

-- 
Sebastien Vauban

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: New exporter and dates in tables
  2013-04-13 17:33                       ` Nicolas Goaziou
  2013-04-13 21:07                         ` Sebastien Vauban
@ 2013-04-14  8:58                         ` Bastien
  2013-04-14 13:37                           ` Nicolas Goaziou
  1 sibling, 1 reply; 31+ messages in thread
From: Bastien @ 2013-04-14  8:58 UTC (permalink / raw)
  To: Nicolas Goaziou; +Cc: Bernt Hansen, emacs-orgmode, Carsten Dominik

Hi Nicolas,

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Bastien <bzg@gnu.org> writes:
>
>> I would find it both cleaner and more useful for users to extend
>> `org-export-with-timestamps' with three choices:
>>
>>   'inactive-not-standalone
>>     'active-not-standalone
>>            'not-standalone
>
> This is a different idea. The change would happen at the exporter level,
> not at parser's.

Yes.

> If we agree to the "alone in a paragraph" part, I can implement it.
>
> But we still need exceptions for clocks and timestamps (i.e., ignore
> `org-export-with-timestamps' value when `org-export-with-planning' or
> `org-export-with-clocks' is non-nil).

Let's not implement my proposal and stick to your implementation of
the exceptions you first proposed.

I expect users will want a way to get rid of <time-stamp> in

* Task
  <time-stamp>

without getting rid of time-stamps in paragraphs, but this can be
tackled later on I guess.

Thanks,

-- 
 Bastien

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: New exporter and dates in tables
  2013-04-13 21:07                         ` Sebastien Vauban
@ 2013-04-14  9:10                           ` Bastien
  0 siblings, 0 replies; 31+ messages in thread
From: Bastien @ 2013-04-14  9:10 UTC (permalink / raw)
  To: Sebastien Vauban; +Cc: public-emacs-orgmode-mXXj517/zsQ



"Sebastien Vauban"
<wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org> writes:

> Wouldn't it be a good moment to introduce
>
>   APPT: <2013-04-13 Sat>
>
> or maybe better named
>
>   EVENT: <2013-04-13 Sat>
>
> for things that only apply for today?

In master, there is the new agenda entry type :scheduled* and the
new agenda type agenda*.  So you can have an agenda* view with a
local value of `org-scheduled-past-days' set to 0: this will list
appointments (i.e. a scheduled item with an hour) only on the date
they are set.

PS: Wrt the "good moment" pattern, I think we abused it already too
much: just because there is a big release to come does not mean we
should include more big changes.  I'm guilty of indulging too much
in this direction... so I'm now more cautious.  Especially when
the change is quite orthogonal to other features, in which case
there is no problem for waiting another release.

-- 
 Bastien

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: New exporter and dates in tables
  2013-04-14  8:58                         ` Bastien
@ 2013-04-14 13:37                           ` Nicolas Goaziou
  2013-04-14 13:45                             ` Bastien
  0 siblings, 1 reply; 31+ messages in thread
From: Nicolas Goaziou @ 2013-04-14 13:37 UTC (permalink / raw)
  To: Bastien; +Cc: Bernt Hansen, emacs-orgmode, Carsten Dominik

Hello,

Bastien <bzg@gnu.org> writes:

> Let's not implement my proposal and stick to your implementation of
> the exceptions you first proposed.

Before we throw the baby out with the bath water, I want to make sure we
are understanding each other.

> I expect users will want a way to get rid of <time-stamp> in
>
> * Task
>   <time-stamp>
>
> without getting rid of time-stamps in paragraphs, but this can be
> tackled later on I guess.

According to your suggestion, with `org-export-with-timestamps' set to
`not-standalone', in the following example:

--8<---------------cut here---------------start------------->8---
* Task
  <timestamp>

At <timestamp>, I must do that.
--8<---------------cut here---------------end--------------->8---

the first <timestamp> would be ignored, not the second one. Isn't it
what you want?

Also, we can do it the TDD way: just throw in a bunch of examples and
we'll come up with an implementation that conforms to all of them (if
they are reasonable enough).


Regards,

-- 
Nicolas Goaziou

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: New exporter and dates in tables
  2013-04-14 13:37                           ` Nicolas Goaziou
@ 2013-04-14 13:45                             ` Bastien
  2013-04-14 13:47                               ` Nicolas Goaziou
  0 siblings, 1 reply; 31+ messages in thread
From: Bastien @ 2013-04-14 13:45 UTC (permalink / raw)
  To: Nicolas Goaziou; +Cc: Bernt Hansen, emacs-orgmode, Carsten Dominik

Hi Nicolas,

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> According to your suggestion, with `org-export-with-timestamps' set to
> `not-standalone', in the following example:
>
> * Task
>   <timestamp>
>
> At <timestamp>, I must do that.
>
> the first <timestamp> would be ignored, not the second one. Isn't it
> what you want?

Yes, exactly.

-- 
 Bastien

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: New exporter and dates in tables
  2013-04-14 13:45                             ` Bastien
@ 2013-04-14 13:47                               ` Nicolas Goaziou
  2013-04-14 14:01                                 ` Bastien
  0 siblings, 1 reply; 31+ messages in thread
From: Nicolas Goaziou @ 2013-04-14 13:47 UTC (permalink / raw)
  To: Bastien; +Cc: Bernt Hansen, emacs-orgmode, Carsten Dominik

Bastien <bzg@gnu.org> writes:

> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>
>> According to your suggestion, with `org-export-with-timestamps' set to
>> `not-standalone', in the following example:
>>
>> * Task
>>   <timestamp>
>>
>> At <timestamp>, I must do that.
>>
>> the first <timestamp> would be ignored, not the second one. Isn't it
>> what you want?
>
> Yes, exactly.

Then why do you suggest to drop the idea (for now)?


Regards,

-- 
Nicolas Goaziou

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: New exporter and dates in tables
  2013-04-14 13:47                               ` Nicolas Goaziou
@ 2013-04-14 14:01                                 ` Bastien
  2013-04-14 14:06                                   ` Nicolas Goaziou
  0 siblings, 1 reply; 31+ messages in thread
From: Bastien @ 2013-04-14 14:01 UTC (permalink / raw)
  To: Nicolas Goaziou; +Cc: Bernt Hansen, emacs-orgmode, Carsten Dominik

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Then why do you suggest to drop the idea (for now)?

Because IIUC, the time-stamps would not be ignored here

* Task
  <2013-04-14 dim.>
  <2013-04-16 dim.>

because

  <2013-04-14 dim.>
  <2013-04-16 dim.>

is a paragraph.  (The agenda takes both time-stamps into
account in a simple `org-agenda-list'.)  If we can remove
the one-time-stamp only case, but not the case with two,
it is too confusing IMHO.

What do you think?

-- 
 Bastien

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: New exporter and dates in tables
  2013-04-14 14:01                                 ` Bastien
@ 2013-04-14 14:06                                   ` Nicolas Goaziou
  2013-04-14 14:24                                     ` Bastien
  0 siblings, 1 reply; 31+ messages in thread
From: Nicolas Goaziou @ 2013-04-14 14:06 UTC (permalink / raw)
  To: Bastien; +Cc: Bernt Hansen, emacs-orgmode, Carsten Dominik

Bastien <bzg@gnu.org> writes:

> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>
>> Then why do you suggest to drop the idea (for now)?
>
> Because IIUC, the time-stamps would not be ignored here
>
> * Task
>   <2013-04-14 dim.>
>   <2013-04-16 dim.>
>
> because
>
>   <2013-04-14 dim.>
>   <2013-04-16 dim.>
>
> is a paragraph.  (The agenda takes both time-stamps into
> account in a simple `org-agenda-list'.)  If we can remove
> the one-time-stamp only case, but not the case with two,
> it is too confusing IMHO.

Correct.

> What do you think?

We can widen the definition of `standalone': a standalone timestamp is
a timestamp belonging to a paragraph that contains only timestamps
objects.


Regards,

-- 
Nicolas Goaziou

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: New exporter and dates in tables
  2013-04-14 14:06                                   ` Nicolas Goaziou
@ 2013-04-14 14:24                                     ` Bastien
  2013-04-14 20:36                                       ` Nicolas Goaziou
  0 siblings, 1 reply; 31+ messages in thread
From: Bastien @ 2013-04-14 14:24 UTC (permalink / raw)
  To: Nicolas Goaziou; +Cc: Bernt Hansen, emacs-orgmode, Carsten Dominik

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> We can widen the definition of `standalone': a standalone timestamp is
> a timestamp belonging to a paragraph that contains only timestamps
> objects.

Great.  If that's possible, then I think that's the best solution.

-- 
 Bastien

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: New exporter and dates in tables
  2013-04-14 14:24                                     ` Bastien
@ 2013-04-14 20:36                                       ` Nicolas Goaziou
  2013-04-15  3:58                                         ` Jambunathan K
                                                           ` (2 more replies)
  0 siblings, 3 replies; 31+ messages in thread
From: Nicolas Goaziou @ 2013-04-14 20:36 UTC (permalink / raw)
  To: Bastien; +Cc: Bernt Hansen, emacs-orgmode, Carsten Dominik

[-- Attachment #1: Type: text/plain, Size: 661 bytes --]

Bastien <bzg@gnu.org> writes:

> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>
>> We can widen the definition of `standalone': a standalone timestamp is
>> a timestamp belonging to a paragraph that contains only timestamps
>> objects.
>
> Great.  If that's possible, then I think that's the best solution.

The following patch should do that. It comes with tests, but it should
be tested extensively, if only to know if this feature is as useful as
it seems.

Note that another option is to allow all timestamps, put timestamps you
don't want to export in a specific drawer (e.g. "TIME"), and ignore this
drawer during export.


Regards,

-- 
Nicolas Goaziou

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-ox-Add-more-options-to-skip-timestamps.patch --]
[-- Type: text/x-patch, Size: 7072 bytes --]

From 8faa562ce1d2a80988736e7a045b7c16aba7ebc9 Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou <n.goaziou@gmail.com>
Date: Sun, 14 Apr 2013 22:20:16 +0200
Subject: [PATCH] ox: Add more options to skip timestamps

* lisp/ox.el (org-export-with-timestamps): Allow `not-standalone',
  `active-not-standalone' and `inactive-not-standalone' values. Update
  docstring.
(org-export--skip-p): Skip timestamps according to new values.
* testing/lisp/test-ox.el: Add tests.
---
 lisp/ox.el              | 59 ++++++++++++++++++++++++++----------
 testing/lisp/test-ox.el | 79 +++++++++++++++++++++++++++++++++++++++----------
 2 files changed, 107 insertions(+), 31 deletions(-)

diff --git a/lisp/ox.el b/lisp/ox.el
index fffb7ce..75ea25a 100644
--- a/lisp/ox.el
+++ b/lisp/ox.el
@@ -721,9 +721,19 @@ also be set with the OPTIONS keyword, e.g. \"timestamp:nil\"."
 (defcustom org-export-with-timestamps t
   "Non nil means allow timestamps in export.
 
-It can be set to `active', `inactive', t or nil, in order to
-export, respectively, only active timestamps, only inactive ones,
-all of them or none.
+It can be set to any of the following values:
+                        t export all timestamps.
+                 `active' export active timestamps only.
+  `active-not-standalone' export active timestamps which are not
+                          isolated in a paragraph containing only
+                          timestamps.
+               `inactive' export inactive timestamps only.
+`inactive-not-standalone' export inactive timestamps which are not
+                          isolated in a paragraph containing only
+                          timestamps.
+         `not-standalone' export timestamps which are not isolated
+                          in a paragraph containing only timestamps.
+                      nil do not export timestamps
 
 This option can also be set with the OPTIONS keyword, e.g.
 \"<:nil\"."
@@ -2017,19 +2027,36 @@ a tree with a select tag."
 	  (not (org-export-get-previous-element blob options))))
     (table-row (org-export-table-row-is-special-p blob options))
     (timestamp
-     (case (plist-get options :with-timestamps)
-       ;; No timestamp allowed.
-       ('nil t)
-       ;; Only active timestamps allowed and the current one isn't
-       ;; active.
-       (active
-	(not (memq (org-element-property :type blob)
-		   '(active active-range))))
-       ;; Only inactive timestamps allowed and the current one isn't
-       ;; inactive.
-       (inactive
-	(not (memq (org-element-property :type blob)
-		   '(inactive inactive-range))))))))
+     (let ((standalonep
+	    (lambda (ts)
+	      ;; Return a non-nil value when TS is a timestamp object
+	      ;; in a paragraph with only timestamps and whitespaces.
+	      (let ((parent (org-export-get-parent-element ts)))
+		(when (memq (org-element-type parent) '(paragraph verse-block))
+		  (not
+		   (org-element-map parent
+		       (cons 'plain-text
+			     (remq 'timestamp org-element-all-objects))
+		     (lambda (obj)
+		       (or (not (stringp obj)) (org-string-nw-p obj)))
+		     options t)))))))
+       (case (plist-get options :with-timestamps)
+	 ('nil t)
+	 (active
+	  (not (memq (org-element-property :type blob) '(active active-range))))
+	 (active-not-standalone
+	  (not (and (memq (org-element-property :type blob)
+			  '(active active-range))
+		    (not (funcall standalonep blob)))))
+	 (inactive-not-standalone
+	  (not
+	   (and (memq (org-element-property :type blob)
+		      '(inactive inactive-range))
+		(not (funcall standalonep blob)))))
+	 (inactive
+	  (not (memq (org-element-property :type blob)
+		     '(inactive inactive-range))))
+	 (not-standalone (funcall standalonep blob)))))))
 
 \f
 ;;; The Transcoder
diff --git a/testing/lisp/test-ox.el b/testing/lisp/test-ox.el
index 46531a1..90b4eb5 100644
--- a/testing/lisp/test-ox.el
+++ b/testing/lisp/test-ox.el
@@ -394,21 +394,70 @@ Paragraph"
 	  (org-test-with-temp-text "[0/0]"
 	    (org-test-with-backend test
 	      (org-export-as
-	       'test nil nil nil '(:with-statistics-cookies nil))))))
-  ;; Timestamps.
-  (org-test-with-temp-text "[2012-04-29 sun. 10:45]<2012-04-29 sun. 10:45>"
-    (org-test-with-backend test
-      (should
-       (equal (org-export-as 'test nil nil nil '(:with-timestamps t))
-	      "[2012-04-29 sun. 10:45]<2012-04-29 sun. 10:45>\n"))
-      (should
-       (equal (org-export-as 'test nil nil nil '(:with-timestamps nil)) ""))
-      (should
-       (equal (org-export-as 'test nil nil nil '(:with-timestamps active))
-	      "<2012-04-29 sun. 10:45>\n"))
-      (should
-       (equal (org-export-as 'test nil nil nil '(:with-timestamps inactive))
-	      "[2012-04-29 sun. 10:45]\n")))))
+	       'test nil nil nil '(:with-statistics-cookies nil)))))))
+
+(ert-deftest test-org-export/with-timestamps ()
+  "Test `org-export-with-timestamps' specifications."
+  ;; t value.
+  (should
+   (equal
+    "[2012-04-29 sun. 10:45]<2012-04-29 sun. 10:45>\n"
+    (org-test-with-temp-text "[2012-04-29 sun. 10:45]<2012-04-29 sun. 10:45>"
+      (org-test-with-backend test
+	(org-export-as 'test nil nil nil '(:with-timestamps t))))))
+  ;; nil value.
+  (should
+   (equal
+    ""
+    (org-test-with-temp-text "[2012-04-29 sun. 10:45]<2012-04-29 sun. 10:45>"
+      (org-test-with-backend test
+	(org-export-as 'test nil nil nil '(:with-timestamps nil))))))
+  ;; `active' value.
+  (should
+   (equal
+    "<2012-04-29 sun. 10:45>\n"
+    (org-test-with-temp-text "[2012-04-29 sun. 10:45]<2012-04-29 sun. 10:45>"
+      (org-test-with-backend test
+	(org-export-as 'test nil nil nil '(:with-timestamps active))))))
+  ;; `active-not-standalone' value.
+  (should
+   (equal
+    "Paragraph <2012-03-29 Thu>"
+    (org-test-with-temp-text
+	"<2012-04-29 Thu>\n\nParagraph <2012-03-29 Thu> [2012-03-29 Thu]"
+      (org-test-with-backend test
+	(org-trim
+	 (org-export-as 'test nil nil nil
+			'(:with-timestamps active-not-standalone)))))))
+  ;; `inactive' value.
+  (should
+   (equal
+    "[2012-04-29 sun. 10:45]\n"
+    (org-test-with-temp-text "[2012-04-29 sun. 10:45]<2012-04-29 sun. 10:45>"
+      (org-test-with-backend test
+	(org-export-as 'test nil nil nil '(:with-timestamps inactive))))))
+  ;; `inactive-not-standalone' value.
+  (should
+   (equal
+    "Paragraph [2012-03-29 Thu]"
+    (org-test-with-temp-text
+	"[2012-04-29 Thu]\n\nParagraph <2012-03-29 Thu> [2012-03-29 Thu]"
+      (org-test-with-backend test
+	(org-trim
+	 (org-export-as 'test nil nil nil
+			'(:with-timestamps inactive-not-standalone)))))))
+  ;; `not-standalone' value.
+  (should
+   (equal
+    "Paragraph <2012-03-29 Thu> [2012-03-29 Thu]\n| [2012-03-29 Thu] |"
+    (org-test-with-temp-text "<2012-03-29 Thu> [2012-04-29 Thu]
+
+Paragraph <2012-03-29 Thu> [2012-03-29 Thu]
+| [2012-03-29 Thu] |"
+      (org-test-with-backend test
+	(org-trim
+	 (org-export-as 'test nil nil nil
+			'(:with-timestamps not-standalone))))))))
 
 (ert-deftest test-org-export/comment-tree ()
   "Test if export process ignores commented trees."
-- 
1.8.2.1


^ permalink raw reply related	[flat|nested] 31+ messages in thread

* Re: New exporter and dates in tables
  2013-04-14 20:36                                       ` Nicolas Goaziou
@ 2013-04-15  3:58                                         ` Jambunathan K
  2013-04-15  6:44                                         ` Bastien
  2013-04-16  7:48                                         ` Bastien
  2 siblings, 0 replies; 31+ messages in thread
From: Jambunathan K @ 2013-04-15  3:58 UTC (permalink / raw)
  To: Nicolas Goaziou; +Cc: emacs-orgmode


Nicolas

You may want to extract the below function as a useful API.

You can then plug that in into `org-odt--standalone-link-p' and it's
counterpart in ox-html.el.  

I am not closely tracking changes in ox-html.el, so things might have
moved since.

Jambunathan K.

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> +	    (lambda (ts)
> +	      ;; Return a non-nil value when TS is a timestamp object
> +	      ;; in a paragraph with only timestamps and whitespaces.
> +	      (let ((parent (org-export-get-parent-element ts)))
> +		(when (memq (org-element-type parent) '(paragraph verse-block))
> +		  (not
> +		   (org-element-map parent
> +		       (cons 'plain-text
> +			     (remq 'timestamp org-element-all-objects))
> +		     (lambda (obj)
> +		       (or (not (stringp obj)) (org-string-nw-p obj)))
> +		     options t)))))

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: New exporter and dates in tables
  2013-04-14 20:36                                       ` Nicolas Goaziou
  2013-04-15  3:58                                         ` Jambunathan K
@ 2013-04-15  6:44                                         ` Bastien
  2013-04-16  7:48                                         ` Bastien
  2 siblings, 0 replies; 31+ messages in thread
From: Bastien @ 2013-04-15  6:44 UTC (permalink / raw)
  To: Nicolas Goaziou; +Cc: Bernt Hansen, emacs-orgmode, Carsten Dominik

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> The following patch should do that. It comes with tests, but it should
> be tested extensively, if only to know if this feature is as useful as
> it seems.

Thanks a lot.  I will not be online for the next 5 hours, but I'll
think about this.

-- 
 Bastien

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: New exporter and dates in tables
  2013-04-14 20:36                                       ` Nicolas Goaziou
  2013-04-15  3:58                                         ` Jambunathan K
  2013-04-15  6:44                                         ` Bastien
@ 2013-04-16  7:48                                         ` Bastien
  2013-08-09  9:35                                           ` Carsten Dominik
  2 siblings, 1 reply; 31+ messages in thread
From: Bastien @ 2013-04-16  7:48 UTC (permalink / raw)
  To: Nicolas Goaziou; +Cc: Bernt Hansen, emacs-orgmode, Carsten Dominik

Hi Nicolas,

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Bastien <bzg@gnu.org> writes:
>
>> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>>
>>> We can widen the definition of `standalone': a standalone timestamp is
>>> a timestamp belonging to a paragraph that contains only timestamps
>>> objects.
>>
>> Great.  If that's possible, then I think that's the best solution.
>
> The following patch should do that. It comes with tests, but it should
> be tested extensively, if only to know if this feature is as useful as
> it seems.

I think I nailed down the root of the confusion.

org-export-with-planning does the job that org-export-with-timestamps
used to do.  So first of all, org-export-with-timestamps should be an
alias to org-export-with-planning so that users who customized
org-export-with-timestamps don't have to change their customization:

(define-obsolete-variable-alias 'org-export-with-timestamps
                                'org-export-with-planning "24.4")

Today, org-export-with-timestamps does a completely different job,
more fine-grained than the old org-export-with-timestamps.  I suggest
to rename it to org-export-with-individual-timestamps and to use the
latest patch you sent, with a default value of t.  I expect the next
useful value is 'not-standalone.  But if someone wants to get rid of
time-stamps in tables or in lists, he now can.

> Note that another option is to allow all timestamps, put timestamps you
> don't want to export in a specific drawer (e.g. "TIME"), and ignore this
> drawer during export.

Yes, but that requires educating users, which I don't really like.

Thanks,

-- 
 Bastien

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: New exporter and dates in tables
  2013-04-16  7:48                                         ` Bastien
@ 2013-08-09  9:35                                           ` Carsten Dominik
  2013-08-09 11:02                                             ` Bernt Hansen
  0 siblings, 1 reply; 31+ messages in thread
From: Carsten Dominik @ 2013-08-09  9:35 UTC (permalink / raw)
  To: Bastien; +Cc: Bernt Hansen, emacs-orgmode, Nicolas Goaziou

Hi guys,

did you arrive at a conclusion of this thread, or is this still open?

Thanks

- Carsten

On 16.4.2013, at 09:48, Bastien <bzg@gnu.org> wrote:

> Hi Nicolas,
> 
> Nicolas Goaziou <n.goaziou@gmail.com> writes:
> 
>> Bastien <bzg@gnu.org> writes:
>> 
>>> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>>> 
>>>> We can widen the definition of `standalone': a standalone timestamp is
>>>> a timestamp belonging to a paragraph that contains only timestamps
>>>> objects.
>>> 
>>> Great.  If that's possible, then I think that's the best solution.
>> 
>> The following patch should do that. It comes with tests, but it should
>> be tested extensively, if only to know if this feature is as useful as
>> it seems.
> 
> I think I nailed down the root of the confusion.
> 
> org-export-with-planning does the job that org-export-with-timestamps
> used to do.  So first of all, org-export-with-timestamps should be an
> alias to org-export-with-planning so that users who customized
> org-export-with-timestamps don't have to change their customization:
> 
> (define-obsolete-variable-alias 'org-export-with-timestamps
>                                'org-export-with-planning "24.4")
> 
> Today, org-export-with-timestamps does a completely different job,
> more fine-grained than the old org-export-with-timestamps.  I suggest
> to rename it to org-export-with-individual-timestamps and to use the
> latest patch you sent, with a default value of t.  I expect the next
> useful value is 'not-standalone.  But if someone wants to get rid of
> time-stamps in tables or in lists, he now can.
> 
>> Note that another option is to allow all timestamps, put timestamps you
>> don't want to export in a specific drawer (e.g. "TIME"), and ignore this
>> drawer during export.
> 
> Yes, but that requires educating users, which I don't really like.
> 
> Thanks,
> 
> -- 
> Bastien

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: New exporter and dates in tables
  2013-08-09  9:35                                           ` Carsten Dominik
@ 2013-08-09 11:02                                             ` Bernt Hansen
  2013-08-12  5:45                                               ` Carsten Dominik
  0 siblings, 1 reply; 31+ messages in thread
From: Bernt Hansen @ 2013-08-09 11:02 UTC (permalink / raw)
  To: Carsten Dominik; +Cc: Bastien, Nicolas Goaziou, emacs-orgmode

Hi Carsten!

All of my headings are followed by an inactive timestamp.  I've started
leaving a blank line before the content for the heading so the inactive
timestamp is not exported when timestamps are disabled with the <:nil
option.  This works fine for me.

Regards,
Bernt

Carsten Dominik <carsten.dominik@gmail.com> writes:

> Hi guys,
>
> did you arrive at a conclusion of this thread, or is this still open?
>
> Thanks
>
> - Carsten
>
> On 16.4.2013, at 09:48, Bastien <bzg@gnu.org> wrote:
>
>> Hi Nicolas,
>> 
>> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>> 
>>> Bastien <bzg@gnu.org> writes:
>>> 
>>>> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>>>> 
>>>>> We can widen the definition of `standalone': a standalone timestamp is
>>>>> a timestamp belonging to a paragraph that contains only timestamps
>>>>> objects.
>>>> 
>>>> Great.  If that's possible, then I think that's the best solution.
>>> 
>>> The following patch should do that. It comes with tests, but it should
>>> be tested extensively, if only to know if this feature is as useful as
>>> it seems.
>> 
>> I think I nailed down the root of the confusion.
>> 
>> org-export-with-planning does the job that org-export-with-timestamps
>> used to do.  So first of all, org-export-with-timestamps should be an
>> alias to org-export-with-planning so that users who customized
>> org-export-with-timestamps don't have to change their customization:
>> 
>> (define-obsolete-variable-alias 'org-export-with-timestamps
>>                                'org-export-with-planning "24.4")
>> 
>> Today, org-export-with-timestamps does a completely different job,
>> more fine-grained than the old org-export-with-timestamps.  I suggest
>> to rename it to org-export-with-individual-timestamps and to use the
>> latest patch you sent, with a default value of t.  I expect the next
>> useful value is 'not-standalone.  But if someone wants to get rid of
>> time-stamps in tables or in lists, he now can.
>> 
>>> Note that another option is to allow all timestamps, put timestamps you
>>> don't want to export in a specific drawer (e.g. "TIME"), and ignore this
>>> drawer during export.
>> 
>> Yes, but that requires educating users, which I don't really like.
>> 
>> Thanks,
>> 
>> -- 
>> Bastien

^ permalink raw reply	[flat|nested] 31+ messages in thread

* Re: New exporter and dates in tables
  2013-08-09 11:02                                             ` Bernt Hansen
@ 2013-08-12  5:45                                               ` Carsten Dominik
  0 siblings, 0 replies; 31+ messages in thread
From: Carsten Dominik @ 2013-08-12  5:45 UTC (permalink / raw)
  To: Bernt Hansen; +Cc: Bastien, Nicolas Goaziou, emacs-orgmode

OK, thank you.

- Carsten

On 9.8.2013, at 13:02, Bernt Hansen <bernt@norang.ca> wrote:

> Hi Carsten!
> 
> All of my headings are followed by an inactive timestamp.  I've started
> leaving a blank line before the content for the heading so the inactive
> timestamp is not exported when timestamps are disabled with the <:nil
> option.  This works fine for me.
> 
> Regards,
> Bernt
> 
> Carsten Dominik <carsten.dominik@gmail.com> writes:
> 
>> Hi guys,
>> 
>> did you arrive at a conclusion of this thread, or is this still open?
>> 
>> Thanks
>> 
>> - Carsten
>> 
>> On 16.4.2013, at 09:48, Bastien <bzg@gnu.org> wrote:
>> 
>>> Hi Nicolas,
>>> 
>>> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>>> 
>>>> Bastien <bzg@gnu.org> writes:
>>>> 
>>>>> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>>>>> 
>>>>>> We can widen the definition of `standalone': a standalone timestamp is
>>>>>> a timestamp belonging to a paragraph that contains only timestamps
>>>>>> objects.
>>>>> 
>>>>> Great.  If that's possible, then I think that's the best solution.
>>>> 
>>>> The following patch should do that. It comes with tests, but it should
>>>> be tested extensively, if only to know if this feature is as useful as
>>>> it seems.
>>> 
>>> I think I nailed down the root of the confusion.
>>> 
>>> org-export-with-planning does the job that org-export-with-timestamps
>>> used to do.  So first of all, org-export-with-timestamps should be an
>>> alias to org-export-with-planning so that users who customized
>>> org-export-with-timestamps don't have to change their customization:
>>> 
>>> (define-obsolete-variable-alias 'org-export-with-timestamps
>>>                               'org-export-with-planning "24.4")
>>> 
>>> Today, org-export-with-timestamps does a completely different job,
>>> more fine-grained than the old org-export-with-timestamps.  I suggest
>>> to rename it to org-export-with-individual-timestamps and to use the
>>> latest patch you sent, with a default value of t.  I expect the next
>>> useful value is 'not-standalone.  But if someone wants to get rid of
>>> time-stamps in tables or in lists, he now can.
>>> 
>>>> Note that another option is to allow all timestamps, put timestamps you
>>>> don't want to export in a specific drawer (e.g. "TIME"), and ignore this
>>>> drawer during export.
>>> 
>>> Yes, but that requires educating users, which I don't really like.
>>> 
>>> Thanks,
>>> 
>>> -- 
>>> Bastien

^ permalink raw reply	[flat|nested] 31+ messages in thread

end of thread, other threads:[~2013-08-12  5:45 UTC | newest]

Thread overview: 31+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-04-08  0:05 New exporter and dates in tables Bernt Hansen
2013-04-08  2:18 ` Mike McLean
2013-04-08  6:57 ` Nicolas Goaziou
2013-04-08 11:27   ` Bernt Hansen
2013-04-08 11:33     ` Carsten Dominik
2013-04-08 19:49       ` Nicolas Goaziou
2013-04-09 13:06         ` Carsten Dominik
2013-04-10 12:43           ` Nicolas Goaziou
2013-04-10 13:12             ` Carsten Dominik
2013-04-10 13:16             ` Bastien
2013-04-11 11:28               ` Nicolas Goaziou
2013-04-11 15:49                 ` Bastien
2013-04-13 10:54                   ` Nicolas Goaziou
2013-04-13 14:02                     ` Bastien
2013-04-13 17:33                       ` Nicolas Goaziou
2013-04-13 21:07                         ` Sebastien Vauban
2013-04-14  9:10                           ` Bastien
2013-04-14  8:58                         ` Bastien
2013-04-14 13:37                           ` Nicolas Goaziou
2013-04-14 13:45                             ` Bastien
2013-04-14 13:47                               ` Nicolas Goaziou
2013-04-14 14:01                                 ` Bastien
2013-04-14 14:06                                   ` Nicolas Goaziou
2013-04-14 14:24                                     ` Bastien
2013-04-14 20:36                                       ` Nicolas Goaziou
2013-04-15  3:58                                         ` Jambunathan K
2013-04-15  6:44                                         ` Bastien
2013-04-16  7:48                                         ` Bastien
2013-08-09  9:35                                           ` Carsten Dominik
2013-08-09 11:02                                             ` Bernt Hansen
2013-08-12  5:45                                               ` Carsten Dominik

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).