[Top][All Lists]

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

Re: [O] please read: bug when marking tasks done

From: cesar mena
Subject: Re: [O] please read: bug when marking tasks done
Date: Thu, 10 Jan 2019 09:15:55 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

hi nicolas,

Nicolas Goaziou <address@hidden> writes:

> Hello,
> cesar mena <address@hidden> writes:
>> from the docstring:
>>   |----------- org-auto-repeat-maybe --------------------------------
>>   |  Check if the *current headline* contains a repeated time-stamp.
>>   |
>>   |  If yes, set TODO state back to what it was and change the base date
>>   |  of repeating *deadline/scheduled time stamps to new date*
>>   |
>>   |  ...
>>   |-----------------------------------------------------------------
>> thus we should not programmatically modify an arbitrary date in a
>> document just because it has a repeater. specially not one buried 300
>> lines deep in a :LOGBOOK: drawer.
>> commit af81211fdc contradicts the established documentation.
> No, it doesn't. "current headline" is to be taken broadly, i.e., in the
> headline or the adjacent section. So, it doesn't matter if a time stamp
> is buried somewhere in the section: it is meant to be updated. 

ok, so "current headline" is taken broadly. but what about the
deadline/scheduled part? what makes a time stamp "deadline/scheduled"?
those are the ones that should change as per the doc.

> Note that it was already the case for active time stamps before said
> commit.

wow! 10 years using org and i didn't know this. 

> For Org syntax, there is no such thing as a state-change entry. They are
> just plain lists. You could write anything in them.

they're plain lists that haven't changed after they've been written. one
could use them for billing reports etc ...

> Now, we might make its contents by marking them as verbatim, for
> example. E.g.,
>   - Rescheduled from =[2019-02-05 Tue .1m]= on [2018-09-29 Sat 18:50]

that's not a bad idea, but what about the other way round?

that is, inactive timestamps with repeaters do not update unless they are
marked as you suggest.  this way current workflows are not affected and
inactive timestamps can be made to update if requested. 

>> an existing entry should not change because one marks a task as DONE.
> I disagree. This has always been the case, at least for active
> time-stamps.

yes, i see where you're coming from. i like to keep it simple.

  (setq org-for-mere-mortal t)


reply via email to

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