[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] Bug: org-clone-subtree-with-time-shift shifts CREATED property o
Re: [O] Bug: org-clone-subtree-with-time-shift shifts CREATED property of org-expiry.el
Thu, 6 Oct 2011 11:24:00 +0200
* Bernt Hansen <address@hidden> wrote:
> Karl Voit <address@hidden> writes:
>> When an entry got processed by org-clone-subtree-with-time-shift,
>> its :CREATED: property gets shifted too:
>> * <2011-10-04 Tue> test
>> SCHEDULED: <2011-10-05 Wed>
>> :CREATED: <2011-10-04 Tue 17:27>
>> * <2011-10-11 Tue> test
>> SCHEDULED: <2011-10-12 Wed>
>> :CREATED: <2011-10-11 Tue 17:27>
> Where does this :CREATED: property come from? The only code I can find
> is in contrib/lisp/org-expiry.el
Yes, I am indeed using this package. To be honest, I have forgotten
that it is org-expiry.el which generates those :CREATED: properties.
But I do find it important to know, *when* an item was created.
Independently from any expiry functionality.
This is not only because I am doing
https://github.com/novoid/Memacs by the way.
> and since that isn't officially part of org-mode yet I don't know
> if it makes sense to have code in the cloning function to handle
Oh, I thought «contrib» is also «part of Org-mode» since it is in
the very same git repository. Thanks for clarification.
> Maybe (if there isn't already) the clone function could use some list of
> properties for special handling (ie drop this property, don't shift the
> date on that property, etc)
> If it can be generically handled then whatever code you include that
> adds functionality for the :CREATED: property can also update that list
> so it is handled in a sensible way.
I can think of different situations where such a mechanism would be
handy, yes. Is Bastien Guerry (creator of org-expiry.el) reading
So for now I am afraid I have to either deactivate org-expiry.el or
remove any :CREATED: property before applying cloning.