emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [PATCH] ox-icalendar: fix handling of timestamps


From: Viktor Rosenfeld
Subject: Re: [O] [PATCH] ox-icalendar: fix handling of timestamps
Date: Sun, 11 Aug 2013 16:14:39 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Hi Nicolas,

Nicolas Goaziou wrote:

> Viktor Rosenfeld <address@hidden> writes:
> 
> > The docstring of `org-icalendar-with-timestamps' already states:
> >
> >   This variable has precedence over `org-export-with-timestamps'.
> >   It can also be set with the #+OPTIONS line, e.g. "<:t".
> 
> This wouldn't be sufficient: "has precedence over" isn't a synonym for
> "change the meaning of".

Okay, I see the change in meaning now.
 
> > I believe that inconsistency is desirable here. Consider the following
> > use case with three headlines:
> >
> > * TODO An appointment in the future
> > <2013-08-12 So 09:00>
> > * DONE A note about an appointment in the past
> > [2013-08-10 Fr 09:00]
> > * WAIT A reminder how long I've been waiting for something [2013-08-10 Fr]
> >
> > The previous behavior, with `org-icalendar-with-timestamps' set to
> > 'active, was that the first and the last headlines were picked up (even
> > though the timestamp in the last headline is inactive). This was
> > unexpected because the two inactive timestamps are handled
> > differently.
> 
> This is to be expected according to `org-export-with-timestamps'.
> 
> > My expectation was that only the first headline should have been
> > exported. This is what my patch achieves.
> 
> The meaning of `org-export-with-timestamps' is the result of a discussion in
> this ML. Please read the whole thread starting at:
> 
>   http://permalink.gmane.org/gmane.emacs.orgmode/69971

Thanks for the link. (It made me realize that something was wrong in my
setup. For some reason, I was picking up `org-export-with-timestamps'
from `org-exp.el', i.e., pre-8.0 code.)

In any case, the docstring of `org-export-with-timestamps' states:

  This only applies to timestamps isolated in a paragraph containing
  only timestamps.  Other timestamps are always exported.

This explains the observerd behavior. But I don't think it's appropriate
for the export to iCal. Quoting Carsten from
http://thread.gmane.org/gmane.emacs.orgmode/69971/focus=70068:

  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.

So the timestamp in the following example is clutter and can be turned
off (i.e., it will not be exported):

  * Meet X
    <2013-08-11 So>

But the following will always be exported, even though the date is just
o note and will not not cause the task to appear in the agenda:

  * Do stuff
    - Started on [2013-08-11 So]

I want to make the iCal export mirror the agenda.

I think the underlying problem is that there is no way in Org to
annotate a timestamp as a fixed appointment. There's SCHEDULED and
DEADLINE, but there's no APPT. The consensus is to use a standalone
active timestamp for fixed appointments, which is easy enough. But then
I would expect only those to appear in an iCal export.

So I propose to append the docstring of
`org-icalendar-export-timestamps':

  This variable has precedence over and overrides the behavior of
  `org-export-with-timestamps'. The setting is applied to every
  timestamp below a headline and not only to those which are isolated in
  a paragraph containing only timestamps.

  It can also be set with the #+OPTIONS line, e.g. "<:t". 

Cheers,
Viktor

(PS: Sorry for the long post.)
> 
> 
> Regards,
> 
> -- 
> Nicolas Goaziou
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]