emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Carsten Dominik <carsten.dominik@gmail.com>
To: Nicolas Goaziou <n.goaziou@gmail.com>
Cc: Bernt Hansen <bernt@norang.ca>, emacs-orgmode@gnu.org
Subject: Re: New exporter and dates in tables
Date: Tue, 9 Apr 2013 15:06:53 +0200	[thread overview]
Message-ID: <173ADFE7-A1FB-4ECB-A78A-C99662A8030F@gmail.com> (raw)
In-Reply-To: <877gkcvm3n.fsf@gmail.com>


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

  reply	other threads:[~2013-04-09 13:07 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=173ADFE7-A1FB-4ECB-A78A-C99662A8030F@gmail.com \
    --to=carsten.dominik@gmail.com \
    --cc=bernt@norang.ca \
    --cc=emacs-orgmode@gnu.org \
    --cc=n.goaziou@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).