Re: [O] New exporter and dates in tables
OK, thank you. - Carsten On 9.8.2013, at 13:02, Bernt Hansen be...@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.domi...@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 b...@gnu.org wrote: Hi Nicolas, Nicolas Goaziou n.goaz...@gmail.com writes: Bastien b...@gnu.org writes: Nicolas Goaziou n.goaz...@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
Re: [O] New exporter and dates in tables
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 b...@gnu.org wrote: Hi Nicolas, Nicolas Goaziou n.goaz...@gmail.com writes: Bastien b...@gnu.org writes: Nicolas Goaziou n.goaz...@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
Re: [O] New exporter and dates in tables
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.domi...@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 b...@gnu.org wrote: Hi Nicolas, Nicolas Goaziou n.goaz...@gmail.com writes: Bastien b...@gnu.org writes: Nicolas Goaziou n.goaz...@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
Re: [O] New exporter and dates in tables
Hi Nicolas, Nicolas Goaziou n.goaz...@gmail.com writes: Bastien b...@gnu.org writes: Nicolas Goaziou n.goaz...@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
Re: [O] New exporter and dates in tables
Nicolas Goaziou n.goaz...@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
Re: [O] New exporter and dates in tables
Hi Nicolas, Nicolas Goaziou n.goaz...@gmail.com writes: Bastien b...@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
Re: [O] New exporter and dates in tables
Sebastien Vauban wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@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
Re: [O] New exporter and dates in tables
Hello, Bastien b...@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
Re: [O] New exporter and dates in tables
Hi Nicolas, Nicolas Goaziou n.goaz...@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
Re: [O] New exporter and dates in tables
Bastien b...@gnu.org writes: Nicolas Goaziou n.goaz...@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
Re: [O] New exporter and dates in tables
Nicolas Goaziou n.goaz...@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
Re: [O] New exporter and dates in tables
Bastien b...@gnu.org writes: Nicolas Goaziou n.goaz...@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
Re: [O] New exporter and dates in tables
Nicolas Goaziou n.goaz...@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
Re: [O] New exporter and dates in tables
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.goaz...@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)
Re: [O] New exporter and dates in tables
Hello, Bastien b...@gnu.org writes: Nicolas Goaziou n.goaz...@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
Re: [O] New exporter and dates in tables
Nicolas Goaziou n.goaz...@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
Re: [O] New exporter and dates in tables
Bastien b...@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
Re: [O] New exporter and dates in tables
Hello, Nicolas Goaziou wrote: Bastien b...@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. 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
Re: [O] New exporter and dates in tables
Hello, Bastien b...@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
Re: [O] New exporter and dates in tables
Hello, Nicolas Goaziou n.goaz...@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
Re: [O] New exporter and dates in tables
Hello,
Carsten Dominik carsten.domi...@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.goaz...@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
Re: [O] New exporter and dates in tables
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.goaz...@gmail.com wrote:
Hello,
Carsten Dominik carsten.domi...@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.goaz...@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 ()
Re: [O] New exporter and dates in tables
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
Re: [O] New exporter and dates in tables
On 8 apr. 2013, at 21:49, Nicolas Goaziou n.goaz...@gmail.com wrote: Hello, Carsten Dominik carsten.domi...@gmail.com writes: On 8 apr. 2013, at 13:27, Bernt Hansen be...@norang.ca wrote: Nicolas Goaziou n.goaz...@gmail.com writes: Bernt Hansen be...@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
Re: [O] New exporter and dates in tables
Hello, Bernt Hansen be...@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
Re: [O] New exporter and dates in tables
Nicolas Goaziou n.goaz...@gmail.com writes: Bernt Hansen be...@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
Re: [O] New exporter and dates in tables
On 8 apr. 2013, at 13:27, Bernt Hansen be...@norang.ca wrote: Nicolas Goaziou n.goaz...@gmail.com writes: Bernt Hansen be...@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
Re: [O] New exporter and dates in tables
Hello, Carsten Dominik carsten.domi...@gmail.com writes: On 8 apr. 2013, at 13:27, Bernt Hansen be...@norang.ca wrote: Nicolas Goaziou n.goaz...@gmail.com writes: Bernt Hansen be...@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
[O] New exporter and dates in tables
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
Re: [O] New exporter and dates in tables
On Apr 7, 2013, at 8:05 PM, Bernt Hansen be...@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.
