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

[Samuel Wales]

sounds like a reasonable fix.

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

[cesar mena]

hello,

Nicolas Goaziou  writes:

> Hello,
>
> cesar mena  writes:
>
>> Nicolas Goaziou  writes:
>>> However, we still need to move forward. So, I suggest to revert the
>>> change about inactive timestamps. Inactive timestamps cannot be
>>> repeated. This is less disruptive than the current situation. 
>>
>> yes, agreed.
>
> Done in maint.

looks good here. 

thanks nicolas.

best,
-cesar

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

[Nicolas Goaziou]

Hello,

cesar mena  writes:

> Nicolas Goaziou  writes:
>> However, we still need to move forward. So, I suggest to revert the
>> change about inactive timestamps. Inactive timestamps cannot be
>> repeated. This is less disruptive than the current situation. 
>
> yes, agreed.

Done in maint.

>> However, I also suggest to add a new hook, run after repeating
>> timestamps. With this hook, and a proper, user-specific, markup, it
>> should be possible to pick inactive timestamps in the section and
>> "repeat" them manually, i.e., on a case-by-case basis.

Done too.

> another (maybe crazy) idea is to advise org-auto-repeat-maybe and set
> org-repeat-re as needed before it gets called.

It is possible, but should be done on the user side, not on the Org one.

Regards,

-- 
Nicolas Goaziou

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

[cesar mena]

Nicolas Goaziou  writes:

> Hello,
>
> Samuel Wales  writes:
>
>> commented repeater cookies does not have any of the above drawbacks.
>> it might require a 3rd party tool to update its re if that tool uses
>> repeaters.  this is not unprecedented.  the inactive repeater feature
>> might already require a 3rd party tool to update its re.
>>
>> so upon reflection i think i'd go for commentable repeater cookies.
>> it has a bonus too: whenever you turn off a repeater, it can be
>> annoying that it zeroes out the interval.  commenting would fix that.
>>
>> perhaps there is a better, unmentioned solution?
>
> I think commented repeaters add unnecessary overhead to the already
> loaded timestamp syntax. This is, IMO, not a common enough need to
> warrant even a minor syntax change.
>
> However, we still need to move forward. So, I suggest to revert the
> change about inactive timestamps. Inactive timestamps cannot be
> repeated. This is less disruptive than the current situation. 

yes, agreed.

> However, I also suggest to add a new hook, run after repeating
> timestamps. With this hook, and a proper, user-specific, markup, it
> should be possible to pick inactive timestamps in the section and
> "repeat" them manually, i.e., on a case-by-case basis.

another (maybe crazy) idea is to advise org-auto-repeat-maybe and set
org-repeat-re as needed before it gets called.

regards,
-cm

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

[Robert Horn]

Nicolas Goaziou writes:

> However, I also suggest to add a new hook, run after repeating
> timestamps. With this hook, and a proper, user-specific, markup, it
> should be possible to pick inactive timestamps in the section and
> "repeat" them manually, i.e., on a case-by-case basis.
>
> WDYT?
>

I like this solution.  I've got several repeating tasks that do not have
simple rules.  (For example, alternating Monday morning/Thursday evening
and adjusting for local holidays, but different rules in July and
August.)  No simple syntax will ever handle these, but I can easily
write an elisp hook to capture the rules.

--
Robert Horn
rjh...@alum.mit.edu

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

[Nicolas Goaziou]

Hello,

Samuel Wales  writes:

> commented repeater cookies does not have any of the above drawbacks.
> it might require a 3rd party tool to update its re if that tool uses
> repeaters.  this is not unprecedented.  the inactive repeater feature
> might already require a 3rd party tool to update its re.
>
> so upon reflection i think i'd go for commentable repeater cookies.
> it has a bonus too: whenever you turn off a repeater, it can be
> annoying that it zeroes out the interval.  commenting would fix that.
>
> perhaps there is a better, unmentioned solution?

I think commented repeaters add unnecessary overhead to the already
loaded timestamp syntax. This is, IMO, not a common enough need to
warrant even a minor syntax change.

However, we still need to move forward. So, I suggest to revert the
change about inactive timestamps. Inactive timestamps cannot be
repeated. This is less disruptive than the current situation. 

However, I also suggest to add a new hook, run after repeating
timestamps. With this hook, and a proper, user-specific, markup, it
should be possible to pick inactive timestamps in the section and
"repeat" them manually, i.e., on a case-by-case basis.

WDYT?

Regards,

-- 
Nicolas Goaziou

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

[Samuel Wales]

[correction: never mind the ranges part.]

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

[Samuel Wales]

some possibly obvious observations:

nobody will want repeating inactive to be changed by org for the bug
case.  those are sacrosanct in that sense.

but if the variable solution is chosen as the sole solution, setting
it to allow changed inactive repeaters will make logbooks no longer
reliable.  i don't think anybody will want that.

"inactive" means "don't show in agenda unless
org-agenda-include-inactive-timestamps is non-nil".  not "sacrosanct".

while i have no use for inactive repeaters, the feature imo should not
be reverted.  it's a good idea.  imagine saying "the next phase of the
project will be on ...".

for the emphasis solution, not everybody wants the verbatim or code
face in the buffer [can be distracting] or on export ["why that
particular string?"].  verbatim is not always set to default.

some might want to have changed repeating inactive without triggering
the bug and also without using the special faces.

inactive repeaters can exist if you have active repeater events [bare
ts or ranges] and decide to "comment them out" by making them inactive
using shift down on the < or >.  some probably do this.

yet they will not want them changed inadvertently if they set the
variable to non-nil and aren't thinking about that.  surprise.

commented repeater cookies does not have any of the above drawbacks.
it might require a 3rd party tool to update its re if that tool uses
repeaters.  this is not unprecedented.  the inactive repeater feature
might already require a 3rd party tool to update its re.

so upon reflection i think i'd go for commentable repeater cookies.
it has a bonus too: whenever you turn off a repeater, it can be
annoying that it zeroes out the interval.  commenting would fix that.

perhaps there is a better, unmentioned solution?

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

[cesar mena]

hello,

On Sun, Jan 13, 2019 at 3:16 PM Nicolas Goaziou 
wrote:

> Hello,
>
> cesar mena  writes:
>
> > i'm ok going with the verbatim syntax - rescheduled lines will now look
> > like (w/o the double quotes?):
> >
> >   - Rescheduled from =[2019-02-05 Tue .1m]= on [2018-09-29 Sat 18:50]
>
> Thinking about it, another possibility is to add a variable, e.g.,
> `org-repeat-inactive-timestamps', letting the user choose what to do
> with inactive time stamps. I think it would default to nil.
>
> This would be a more conservative solution; however, this would
> contradict releases notes for Org 9.2.
>
> WDYT?
>
>
this works of course and it doesn't affect current workflows while allowing
for inactive repeating timestamps.

the caveat would be that in the case of repeating timestamps, setting both
`org-log-into-drawer' and `org-repeat-inactive-timestamps' to a true value
will overwrite "Rescheduling" entries from the :LOGBOOK:.  in some limited
sense the two are incompatible (which would require the verbatim syntax).

with that understanding, and the fact that repeating inactive timestamps is
a new "feature" my vote is for `org-repeat-inactive-timestamps'.  this
leaves room down the road, should the need arise, for verbatim syntax in
log entries.

regards,
-cm

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

[Bernt Hansen]

Samuel Wales  writes:

> dunno best solution.
>
> another option is to comment out repeater intervals like ;.+2d instead
> of .+0d or =[... .+2d]=.
>
> this would also allow you to know what the interval was [currently
> that information is lost].  it would avoid overloading face.  it would
> be under user control for every ts.  it would, however, require
> updating ts regexp.
>
>
> On 1/13/19, Nicolas Goaziou  wrote:
>> Hello,
>>
>> cesar mena  writes:
>>
>>> i'm ok going with the verbatim syntax - rescheduled lines will now look
>>> like (w/o the double quotes?):
>>>
>>>   - Rescheduled from =[2019-02-05 Tue .1m]= on [2018-09-29 Sat 18:50]
>>
>> Thinking about it, another possibility is to add a variable, e.g.,
>> `org-repeat-inactive-timestamps', letting the user choose what to do
>> with inactive time stamps. I think it would default to nil.
>>
>> This would be a more conservative solution; however, this would
>> contradict releases notes for Org 9.2.
>>
>> WDYT?
>>
>> Regards,
>>
>> --
>> Nicolas Goaziou
>>
>>

I don't have a need for updating any timestamps but the ones in the
SCHEDULED/DEADLINE: entry.  A variable to control behaviour would work
great for me.

Regards,
Bernt

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

[Samuel Wales]

dunno best solution.

another option is to comment out repeater intervals like ;.+2d instead
of .+0d or =[... .+2d]=.

this would also allow you to know what the interval was [currently
that information is lost].  it would avoid overloading face.  it would
be under user control for every ts.  it would, however, require
updating ts regexp.


On 1/13/19, Nicolas Goaziou  wrote:
> Hello,
>
> cesar mena  writes:
>
>> i'm ok going with the verbatim syntax - rescheduled lines will now look
>> like (w/o the double quotes?):
>>
>>   - Rescheduled from =[2019-02-05 Tue .1m]= on [2018-09-29 Sat 18:50]
>
> Thinking about it, another possibility is to add a variable, e.g.,
> `org-repeat-inactive-timestamps', letting the user choose what to do
> with inactive time stamps. I think it would default to nil.
>
> This would be a more conservative solution; however, this would
> contradict releases notes for Org 9.2.
>
> WDYT?
>
> Regards,
>
> --
> Nicolas Goaziou
>
>


-- 
The Kafka Pandemic: 

The disease DOES progress. MANY people have died from it. And ANYBODY
can get it at any time.

"You’ve really gotta quit this and get moving, because this is murder
by neglect." ---
.

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

[Nicolas Goaziou]

Hello,

cesar mena  writes:

> i'm ok going with the verbatim syntax - rescheduled lines will now look
> like (w/o the double quotes?):
>
>   - Rescheduled from =[2019-02-05 Tue .1m]= on [2018-09-29 Sat 18:50]

Thinking about it, another possibility is to add a variable, e.g.,
`org-repeat-inactive-timestamps', letting the user choose what to do
with inactive time stamps. I think it would default to nil.

This would be a more conservative solution; however, this would
contradict releases notes for Org 9.2.

WDYT?

Regards,

-- 
Nicolas Goaziou

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

[Nicolas Goaziou]

Hello,

Samuel Wales  writes:

> manual> Text in the code and
> verbatim string is not processed for Org mode specific syntax, it is
> exported verbatim.
>
> i assumed that meant /during export/.

Only the second part of the sentence refers to exporting. The current
wording is the following, note the punctuation used:

Text in the code and verbatim string is not processed for Org mode
specific syntax; it is exported verbatim.

> it is in the markup section.

The Markup section is a different section than Exporting.

> thus, someplace in manual, perhaps say that verbatim and code have
> more effects than just export.

Feel free to provide a better wording. Although, I find the current one
clear enough.

Regards,

-- 
Nicolas Goaziou

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

[Samuel Wales]

there is a related bug.

when there are multiple repeaters, closing a task with -1 can only
zero the first.

probably it should zero all mutable repeaters.

* MOOT hi
CLOSED: [2019-01-12 Sat 13:54]
<2019-01-13 Sun .+0d>
<2019-01-13 Sun .+1d>
=<2019-01-12 Sat .+1d>=
~<2019-01-12 Sat .+1d>~
hi


On 1/12/19, Samuel Wales  wrote:
> manual> Text in the code and
> verbatim string is not processed for Org mode specific syntax, it is
> exported verbatim.
>
> i assumed that meant /during export/.  it is in the markup section.
>
> thus, someplace in manual, perhaps say that verbatim and code have
> more effects than just export.
>
>
> On 1/12/19, cesar mena  wrote:
>> hello,
>>
>> Nicolas Goaziou  writes:
>>
> 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.
>>>
>>> The other way around is not possible because =...= means "verbatim".
>>> This would be contradictory.
>>
>> i see. i didn't know =...= meant verbatim. so in light of this new
>> knowledge :) your solution makes a lot of sense. i was originally
>> opposed to it because it means current documents will have to change to
>> add =...= but in the end it seems the simplest.
>>
>>> The main question is: what to do with an "inactive time stamp with
>>> repeater".
>>>
>>> The original report, that lead to the incriminated commit, emphasized
>>> the "repeater" part, arguing a repeater should induce the time stamp is
>>> meant to be repeated, notwithstanding its nature.
>>>
>>> You are emphasizing the "inactive" part of it, arguing that anything
>>> inactive should not change dynamically.
>>>
>>> Both arguments can be heard. I agree yours is more conservative. Yet,
>>> I'd like to hear about a solution than can satisfy both. I'm Cc'ing the
>>> OP.
>>
>> i'm ok going with the verbatim syntax - rescheduled lines will now look
>> like (w/o the double quotes?):
>>
>>   - Rescheduled from =[2019-02-05 Tue .1m]= on [2018-09-29 Sat 18:50]
>>
>>> I'm trying to keep Org as simple as possible, but different users have
>>> different use cases, and, in some annoying situations like this one,
>>> these use cases conflict.
>>
>> we are ever grateful.
>>
>> best,
>> -cm
>>
>>
>>
>
>
> --
> The Kafka Pandemic: 
>
> The disease DOES progress. MANY people have died from it. And ANYBODY
> can get it at any time.
>
> "You’ve really gotta quit this and get moving, because this is murder
> by neglect." ---
> .
>


-- 
The Kafka Pandemic: 

The disease DOES progress. MANY people have died from it. And ANYBODY
can get it at any time.

"You’ve really gotta quit this and get moving, because this is murder
by neglect." ---
.

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

[Samuel Wales]

manual> Text in the code and
verbatim string is not processed for Org mode specific syntax, it is
exported verbatim.

i assumed that meant /during export/.  it is in the markup section.

thus, someplace in manual, perhaps say that verbatim and code have
more effects than just export.


On 1/12/19, cesar mena  wrote:
> hello,
>
> Nicolas Goaziou  writes:
>
 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.
>>
>> The other way around is not possible because =...= means "verbatim".
>> This would be contradictory.
>
> i see. i didn't know =...= meant verbatim. so in light of this new
> knowledge :) your solution makes a lot of sense. i was originally
> opposed to it because it means current documents will have to change to
> add =...= but in the end it seems the simplest.
>
>> The main question is: what to do with an "inactive time stamp with
>> repeater".
>>
>> The original report, that lead to the incriminated commit, emphasized
>> the "repeater" part, arguing a repeater should induce the time stamp is
>> meant to be repeated, notwithstanding its nature.
>>
>> You are emphasizing the "inactive" part of it, arguing that anything
>> inactive should not change dynamically.
>>
>> Both arguments can be heard. I agree yours is more conservative. Yet,
>> I'd like to hear about a solution than can satisfy both. I'm Cc'ing the
>> OP.
>
> i'm ok going with the verbatim syntax - rescheduled lines will now look
> like (w/o the double quotes?):
>
>   - Rescheduled from =[2019-02-05 Tue .1m]= on [2018-09-29 Sat 18:50]
>
>> I'm trying to keep Org as simple as possible, but different users have
>> different use cases, and, in some annoying situations like this one,
>> these use cases conflict.
>
> we are ever grateful.
>
> best,
> -cm
>
>
>


-- 
The Kafka Pandemic: 

The disease DOES progress. MANY people have died from it. And ANYBODY
can get it at any time.

"You’ve really gotta quit this and get moving, because this is murder
by neglect." ---
.

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

[cesar mena]

hello,

Nicolas Goaziou  writes:

>>> 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.
>
> The other way around is not possible because =...= means "verbatim".
> This would be contradictory.

i see. i didn't know =...= meant verbatim. so in light of this new
knowledge :) your solution makes a lot of sense. i was originally
opposed to it because it means current documents will have to change to
add =...= but in the end it seems the simplest. 

> The main question is: what to do with an "inactive time stamp with
> repeater".
>
> The original report, that lead to the incriminated commit, emphasized
> the "repeater" part, arguing a repeater should induce the time stamp is
> meant to be repeated, notwithstanding its nature.
>
> You are emphasizing the "inactive" part of it, arguing that anything
> inactive should not change dynamically.
>
> Both arguments can be heard. I agree yours is more conservative. Yet,
> I'd like to hear about a solution than can satisfy both. I'm Cc'ing the
> OP.

i'm ok going with the verbatim syntax - rescheduled lines will now look
like (w/o the double quotes?):

  - Rescheduled from =[2019-02-05 Tue .1m]= on [2018-09-29 Sat 18:50]

> I'm trying to keep Org as simple as possible, but different users have
> different use cases, and, in some annoying situations like this one,
> these use cases conflict.

we are ever grateful.

best,
-cm

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

[Nicolas Goaziou]

Hello,

cesar mena  writes:

> 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.

You are right the docstring is inaccurate here. It is not limited to
scheduled and deadlines, but also to plain time stamps. This is an
important feature.

However, this is not related to the commit we're talking about.

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

Of course.

What I mean is Org has no way to know the meaning of the contents, or
what you want to do with them, if you don't put markers or some special
syntax somewhere.

>> 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.

The other way around is not possible because =...= means "verbatim".
This would be contradictory.

The main question is: what to do with an "inactive time stamp with
repeater".

The original report, that lead to the incriminated commit, emphasized
the "repeater" part, arguing a repeater should induce the time stamp is
meant to be repeated, notwithstanding its nature.

You are emphasizing the "inactive" part of it, arguing that anything
inactive should not change dynamically.

Both arguments can be heard. I agree yours is more conservative. Yet,
I'd like to hear about a solution than can satisfy both. I'm Cc'ing the
OP.

> yes, i see where you're coming from. i like to keep it simple.
>
>   (setq org-for-mere-mortal t)

I'm trying to keep Org as simple as possible, but different users have
different use cases, and, in some annoying situations like this one,
these use cases conflict.

Regards,

-- 
Nicolas Goaziou

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

[cesar mena]

hi nicolas,

Nicolas Goaziou  writes:

> Hello,
>
> cesar mena  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)

best,
-cm

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

[Nicolas Goaziou]

Hello,

cesar mena  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. Note that
it was already the case for active time stamps before said commit.

> but the solution overreaches.

I agree the current state is not ideal, but as I said, the only
suggestion I had was not satisfying. I'm all ears, though.

> apologies if i wasn't clear. what should be immutable is a logged,
> state-change entry.

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

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]

> 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.

Regards,

-- 
Nicolas Goaziou

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

[cesar mena]

hello nicolas,

Nicolas Goaziou  writes:

> Hello,
>
> cesar mena  writes:
>
>> as per the documentation for "org-auto-repeat-maybe" only the base date
>> of repeating deadline/scheduled time stamps should change. AFAICT the
>> patch changes every occurrence of an inactive repeating timestamp that is
>> not a comment.
>
> The base date of a time stamp is the part before the repeater. IOW,
> every time stamp with a repeater has a base date, therefore
> `org-auto-repeat-maybe' changes them all. I see no problem with the
> docstring.

the _base date_ is not the pertinent part; the _deadline/scheduled_ aspect
is.  moreover this should only happen on the headline.

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. 

see bernt hansen's email in this thread for another unintended
consequence. he can't mark a task that is no longer scheduled as DONE
because there is an inactive timestamp in a :LOGBOOK: entry.

> I don't think we agree about the immutable part.

see below for clarification.

> At least, the user who reported the bug solved in
> af81211fdc01b64449179bcdb77fb1c8ecb3fb94 didn't agree.

but the solution overreaches. again, only repeating deadline/scheduled
time stamps should change if they are in the current headline.

> Inactive time stamps are not immutable.

apologies if i wasn't clear. what should be immutable is a logged,
state-change entry. an existing entry should not change because one
marks a task as DONE.

regards,
-cm

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

[Bernt Hansen]

Nicolas Goaziou  writes:

> Anyway, I don't really have any other idea besides dropping the repeater
> part from automatically inserted inactive time stamps. 

When I unschedule (and log) a habit I don't want to lose the detail
about the repeat interval.  My workaround for this is to break the
timestamp by adding a ',' after the '[' in the timestamp so marking it
DONE actually works.

** DONE Weekly Review 2018 [0/16]
 CLOSED: [2019-01-08 Tue 09:19]
:PROPERTIES:...
:LOGBOOK:
- State "DONE"   from "TODO"   [2019-01-08 Tue 09:19]
- Not scheduled, was "[,2019-01-07 Mon ++7d/14d]" on [2019-01-08 Tue
09:18]

Marking this task done is also pretty slow - taking 25 seconds.
The task has 233 lines, 2549 words, and 12993 characters.

partial elp-results for this task below

org-todo   1   25.33 25.33
org-self-insert-command1   25.33 25.33
org-checklist  1   25.12425.124
org-reset-checkbox-state-subtree   1   25.12425.124
org-reset-checkbox-state-maybe 1   25.12425.124
org-update-checkbox-count  1   24.94524.945
org-update-checkbox-count-maybe1   24.94524.945
org-element-at-point   154824.87099  0.0160665374
org-element-context154124.86899  0.0161382219
org-element--parse-to  154424.71899  0.0160097150
org-element--current-element   310922.07099  0.0070990672
org-element-example-block-parser   153719.66499  0.0127944046
org-unescape-code-in-string153713.60400  0.0088510084
org-element-paragraph-parser   15441.77  0.0011528497
org-fast-todo-selection1   0.201 0.201
...

Regards,
Bernt

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

[Nicolas Goaziou]

Hello,

cesar mena  writes:

> as per the documentation for "org-auto-repeat-maybe" only the base date
> of repeating deadline/scheduled time stamps should change. AFAICT the
> patch changes every occurrence of an inactive repeating timestamp that is
> not a comment.

The base date of a time stamp is the part before the repeater. IOW,
every time stamp with a repeater has a base date, therefore
`org-auto-repeat-maybe' changes them all. I see no problem with the
docstring.

>> I think a solution would be to remove the repeater from timestamps
>> inserted upon logging a state change or a re-scheduling.
>
> but that is useful and correct information. it lets me know the state of
> the scheduled timestamp at the time i rescheduled; you are proposing to
> change this to avoid a re-computation for data that i am sure we agree
> should be treated as immutable.

I don't think we agree about the immutable part. At least, the user who
reported the bug solved in af81211fdc01b64449179bcdb77fb1c8ecb3fb94
didn't agree. Inactive time stamps are not immutable.

But the main issue is that I don't understand what useful and correct
information we loose if we drop the repeater part, i.e.:

  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-09-29 Sat 18:50]

to

  - Rescheduled from "[2019-02-05 Tue]" on [2018-09-29 Sat 18:50]

> note that the from dates in the "Rescheduled" line is also in quotes
> indicating that it is textual information. no longer in play. changing
> such dates is akin to changing dates in a comment.
>
> what do you think?

I think quotes are not comment syntax in Org, so it means nothing
programatically.

Anyway, I don't really have any other idea besides dropping the repeater
part from automatically inserted inactive time stamps. 

You may want to read the thread in the commit message referenced above
and possibly discuss with the bug reporter to find an acceptable middle
ground.

Regards,

-- 
Nicolas Goaziou

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

[cesar mena]

hi nicolas,

Nicolas Goaziou  writes:

> Hello,
>
> cesar mena  writes:
>
>> hello everyone,
>>
>> in the maint branch, marking a repeatable task as DONE causes the
>> "Rescheduled from" dates to be lost in the :LOGBOOK:.
>>
>> in the below diff all of the from dates are rewritten with the new
>> scheduled date:
>>
>>   -  SCHEDULED: <2018-12-04 Tue .+1m>
>>   +  SCHEDULED: <2019-02-05 Tue .+1m>
>>  :PROPERTIES:
>>   -  :LAST_REPEAT: [2018-08-08 Wed 07:40]
>>   +  :LAST_REPEAT: [2019-01-05 Sat 18:47]
>>  :END:
>>  :LOGBOOK:
>>   -  - Rescheduled from "[2018-11-28 Wed .+1m]" on [2018-11-28 Wed 08:35]
>>   -  - Rescheduled from "[2018-11-25 Sun .+1m]" on [2018-11-25 Sun 09:17]
>>   -  - Rescheduled from "[2018-11-20 Tue .+1m]" on [2018-11-22 Thu 10:03]
>>   -  - Rescheduled from "[2018-11-13 Tue .+1m]" on [2018-11-17 Sat 09:48]
>>   -  - Rescheduled from "[2018-11-06 Tue .+1m]" on [2018-11-08 Thu 07:02]
>>   -  - Rescheduled from "[2018-10-28 Sun .+1m]" on [2018-10-30 Tue 16:22]
>>   -  - Rescheduled from "[2018-10-25 Thu .+1m]" on [2018-10-25 Thu 07:34]
>>   -  - Rescheduled from "[2018-10-19 Fri .+1m]" on [2018-10-19 Fri 07:48]
>>   -  - Rescheduled from "[2018-10-16 Tue .+1m]" on [2018-10-16 Tue 16:21]
>>   -  - Rescheduled from "[2018-10-11 Thu .+1m]" on [2018-10-14 Sun 10:31]
>>   -  - Rescheduled from "[2018-10-07 Sun .+1m]" on [2018-10-08 Mon 08:48]
>>   -  - Rescheduled from "[2018-09-27 Thu .+1m]" on [2018-09-29 Sat 18:50]
>>   -  - Rescheduled from "[2018-09-20 Thu .+1m]" on [2018-09-20 Thu 09:50]
>>   -  - Rescheduled from "[2018-09-08 Sat .+1m]" on [2018-09-14 Fri 07:10]
>>   +  - State "DONE"   from "TODO"   [2019-01-05 Sat 18:47]
>>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-11-28 Wed 08:35]
>>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-11-25 Sun 09:17]
>>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-11-22 Thu 10:03]
>>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-11-17 Sat 09:48]
>>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-11-08 Thu 07:02]
>>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-10-30 Tue 16:22]
>>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-10-25 Thu 07:34]
>>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-10-19 Fri 07:48]
>>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-10-16 Tue 16:21]
>>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-10-14 Sun 10:31]
>>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-10-08 Mon 08:48]
>>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-09-29 Sat 18:50]
>>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-09-20 Thu 09:50]
>>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-09-14 Fri 07:10]
>>   
>> bisect says it was introduced in
>> af81211fdc01b64449179bcdb77fb1c8ecb3fb94.
>
> Which is a bugfix…

as per the documentation for "org-auto-repeat-maybe" only the base date
of repeating deadline/scheduled time stamps should change. AFAICT the
patch changes every occurrence of an inactive repeating timestamp that is
not a comment.

> I think a solution would be to remove the repeater from timestamps
> inserted upon logging a state change or a re-scheduling.

but that is useful and correct information. it lets me know the state of
the scheduled timestamp at the time i rescheduled; you are proposing to
change this to avoid a re-computation for data that i am sure we agree
should be treated as immutable.

note that the from dates in the "Rescheduled" line is also in quotes
indicating that it is textual information. no longer in play. changing
such dates is akin to changing dates in a comment.

what do you think?

best,
-cm

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

[Bernt Hansen]

Nicolas Goaziou  writes:

> Hello,
>
> cesar mena  writes:
>
>> hello everyone,
>>
>> in the maint branch, marking a repeatable task as DONE causes the
>> "Rescheduled from" dates to be lost in the :LOGBOOK:.
>>
>> in the below diff all of the from dates are rewritten with the new
>> scheduled date:
>>
>>   -  SCHEDULED: <2018-12-04 Tue .+1m>
>>   +  SCHEDULED: <2019-02-05 Tue .+1m>
>>  :PROPERTIES:
>>   -  :LAST_REPEAT: [2018-08-08 Wed 07:40]
>>   +  :LAST_REPEAT: [2019-01-05 Sat 18:47]
>>  :END:
>>  :LOGBOOK:
>>   -  - Rescheduled from "[2018-11-28 Wed .+1m]" on [2018-11-28 Wed 08:35]
>>   -  - Rescheduled from "[2018-11-25 Sun .+1m]" on [2018-11-25 Sun 09:17]
>>   -  - Rescheduled from "[2018-11-20 Tue .+1m]" on [2018-11-22 Thu 10:03]
>>   -  - Rescheduled from "[2018-11-13 Tue .+1m]" on [2018-11-17 Sat 09:48]
>>   -  - Rescheduled from "[2018-11-06 Tue .+1m]" on [2018-11-08 Thu 07:02]
>>   -  - Rescheduled from "[2018-10-28 Sun .+1m]" on [2018-10-30 Tue 16:22]
>>   -  - Rescheduled from "[2018-10-25 Thu .+1m]" on [2018-10-25 Thu 07:34]
>>   -  - Rescheduled from "[2018-10-19 Fri .+1m]" on [2018-10-19 Fri 07:48]
>>   -  - Rescheduled from "[2018-10-16 Tue .+1m]" on [2018-10-16 Tue 16:21]
>>   -  - Rescheduled from "[2018-10-11 Thu .+1m]" on [2018-10-14 Sun 10:31]
>>   -  - Rescheduled from "[2018-10-07 Sun .+1m]" on [2018-10-08 Mon 08:48]
>>   -  - Rescheduled from "[2018-09-27 Thu .+1m]" on [2018-09-29 Sat 18:50]
>>   -  - Rescheduled from "[2018-09-20 Thu .+1m]" on [2018-09-20 Thu 09:50]
>>   -  - Rescheduled from "[2018-09-08 Sat .+1m]" on [2018-09-14 Fri 07:10]
>>   +  - State "DONE"   from "TODO"   [2019-01-05 Sat 18:47]
>>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-11-28 Wed 08:35]
>>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-11-25 Sun 09:17]
>>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-11-22 Thu 10:03]
>>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-11-17 Sat 09:48]
>>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-11-08 Thu 07:02]
>>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-10-30 Tue 16:22]
>>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-10-25 Thu 07:34]
>>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-10-19 Fri 07:48]
>>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-10-16 Tue 16:21]
>>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-10-14 Sun 10:31]
>>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-10-08 Mon 08:48]
>>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-09-29 Sat 18:50]
>>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-09-20 Thu 09:50]
>>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-09-14 Fri 07:10]
>>   
>> bisect says it was introduced in
>> af81211fdc01b64449179bcdb77fb1c8ecb3fb94.
>
> Which is a bugfix…
>
> I think a solution would be to remove the repeater from timestamps
> inserted upon logging a state change or a re-scheduling.
>
> However, you would have to fix your old documents manually.
>
> Regards,

Hi Nicholas,

I think this commit is a problem:

  af81211fd (Also obey to repeaters in inactive time stamps, 2018-11-10)

At the beginning of the year I close my repeating tasks with lots of
logging and clocking entries and create a new one as follows:

1) Clone repeating task to new task for next year
2) Unscheduled old task which writes the scheduled repeater to the log
as above
3) Mark old task DONE 

Step 3 fails.  It moves the repeater in the log message from the old
scheduled task makes the task TODO again.

Example:


* TODO Sample repeating task 2018
  SCHEDULED: <2019-01-07 Mon ++1w>
  :LOGBOOK:
  - Note taken on [2019-01-07 Mon 09:44] \\
Log note 2
  - Note taken on [2019-01-07 Mon 09:44] \\
Log note 1
  :END:
  [2019-01-07 Mon 09:44]



Now clone the task with C-c C-x c 1 RET RET


* TODO Sample repeating task 2018
  SCHEDULED: <2019-01-07 Mon ++1w>
  :LOGBOOK:
  - Note taken on [2019-01-07 Mon 09:44] \\
Log note 2
  - Note taken on [2019-01-07 Mon 09:44] \\
Log note 1
  :END:
  [2019-01-07 Mon 09:44]

* TODO Sample repeating task 2018
  SCHEDULED: <2019-01-07 Mon ++1w>
  :LOGBOOK:
  - Note taken on [2019-01-07 Mon 09:44] \\
Log note 2
  - Note taken on [2019-01-07 Mon 09:44] \\
Log note 1
  :END:
  [2019-01-07 Mon 09:44]


Rename the second task to 2019 and unschedule the first task:


* TODO Sample repeating task 2018
  

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

[Nicolas Goaziou]

Hello,

cesar mena  writes:

> hello everyone,
>
> in the maint branch, marking a repeatable task as DONE causes the
> "Rescheduled from" dates to be lost in the :LOGBOOK:.
>
> in the below diff all of the from dates are rewritten with the new
> scheduled date:
>
>   -  SCHEDULED: <2018-12-04 Tue .+1m>
>   +  SCHEDULED: <2019-02-05 Tue .+1m>
>  :PROPERTIES:
>   -  :LAST_REPEAT: [2018-08-08 Wed 07:40]
>   +  :LAST_REPEAT: [2019-01-05 Sat 18:47]
>  :END:
>  :LOGBOOK:
>   -  - Rescheduled from "[2018-11-28 Wed .+1m]" on [2018-11-28 Wed 08:35]
>   -  - Rescheduled from "[2018-11-25 Sun .+1m]" on [2018-11-25 Sun 09:17]
>   -  - Rescheduled from "[2018-11-20 Tue .+1m]" on [2018-11-22 Thu 10:03]
>   -  - Rescheduled from "[2018-11-13 Tue .+1m]" on [2018-11-17 Sat 09:48]
>   -  - Rescheduled from "[2018-11-06 Tue .+1m]" on [2018-11-08 Thu 07:02]
>   -  - Rescheduled from "[2018-10-28 Sun .+1m]" on [2018-10-30 Tue 16:22]
>   -  - Rescheduled from "[2018-10-25 Thu .+1m]" on [2018-10-25 Thu 07:34]
>   -  - Rescheduled from "[2018-10-19 Fri .+1m]" on [2018-10-19 Fri 07:48]
>   -  - Rescheduled from "[2018-10-16 Tue .+1m]" on [2018-10-16 Tue 16:21]
>   -  - Rescheduled from "[2018-10-11 Thu .+1m]" on [2018-10-14 Sun 10:31]
>   -  - Rescheduled from "[2018-10-07 Sun .+1m]" on [2018-10-08 Mon 08:48]
>   -  - Rescheduled from "[2018-09-27 Thu .+1m]" on [2018-09-29 Sat 18:50]
>   -  - Rescheduled from "[2018-09-20 Thu .+1m]" on [2018-09-20 Thu 09:50]
>   -  - Rescheduled from "[2018-09-08 Sat .+1m]" on [2018-09-14 Fri 07:10]
>   +  - State "DONE"   from "TODO"   [2019-01-05 Sat 18:47]
>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-11-28 Wed 08:35]
>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-11-25 Sun 09:17]
>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-11-22 Thu 10:03]
>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-11-17 Sat 09:48]
>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-11-08 Thu 07:02]
>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-10-30 Tue 16:22]
>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-10-25 Thu 07:34]
>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-10-19 Fri 07:48]
>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-10-16 Tue 16:21]
>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-10-14 Sun 10:31]
>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-10-08 Mon 08:48]
>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-09-29 Sat 18:50]
>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-09-20 Thu 09:50]
>   +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-09-14 Fri 07:10]
>   
> bisect says it was introduced in
> af81211fdc01b64449179bcdb77fb1c8ecb3fb94.

Which is a bugfix…

I think a solution would be to remove the repeater from timestamps
inserted upon logging a state change or a re-scheduling.

However, you would have to fix your old documents manually.

Regards,

-- 
Nicolas Goaziou

[O] please read: bug when marking tasks done

[cesar mena]

hello everyone,

in the maint branch, marking a repeatable task as DONE causes the
"Rescheduled from" dates to be lost in the :LOGBOOK:.

in the below diff all of the from dates are rewritten with the new
scheduled date:

  -  SCHEDULED: <2018-12-04 Tue .+1m>
  +  SCHEDULED: <2019-02-05 Tue .+1m>
 :PROPERTIES:
  -  :LAST_REPEAT: [2018-08-08 Wed 07:40]
  +  :LAST_REPEAT: [2019-01-05 Sat 18:47]
 :END:
 :LOGBOOK:
  -  - Rescheduled from "[2018-11-28 Wed .+1m]" on [2018-11-28 Wed 08:35]
  -  - Rescheduled from "[2018-11-25 Sun .+1m]" on [2018-11-25 Sun 09:17]
  -  - Rescheduled from "[2018-11-20 Tue .+1m]" on [2018-11-22 Thu 10:03]
  -  - Rescheduled from "[2018-11-13 Tue .+1m]" on [2018-11-17 Sat 09:48]
  -  - Rescheduled from "[2018-11-06 Tue .+1m]" on [2018-11-08 Thu 07:02]
  -  - Rescheduled from "[2018-10-28 Sun .+1m]" on [2018-10-30 Tue 16:22]
  -  - Rescheduled from "[2018-10-25 Thu .+1m]" on [2018-10-25 Thu 07:34]
  -  - Rescheduled from "[2018-10-19 Fri .+1m]" on [2018-10-19 Fri 07:48]
  -  - Rescheduled from "[2018-10-16 Tue .+1m]" on [2018-10-16 Tue 16:21]
  -  - Rescheduled from "[2018-10-11 Thu .+1m]" on [2018-10-14 Sun 10:31]
  -  - Rescheduled from "[2018-10-07 Sun .+1m]" on [2018-10-08 Mon 08:48]
  -  - Rescheduled from "[2018-09-27 Thu .+1m]" on [2018-09-29 Sat 18:50]
  -  - Rescheduled from "[2018-09-20 Thu .+1m]" on [2018-09-20 Thu 09:50]
  -  - Rescheduled from "[2018-09-08 Sat .+1m]" on [2018-09-14 Fri 07:10]
  +  - State "DONE"   from "TODO"   [2019-01-05 Sat 18:47]
  +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-11-28 Wed 08:35]
  +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-11-25 Sun 09:17]
  +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-11-22 Thu 10:03]
  +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-11-17 Sat 09:48]
  +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-11-08 Thu 07:02]
  +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-10-30 Tue 16:22]
  +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-10-25 Thu 07:34]
  +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-10-19 Fri 07:48]
  +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-10-16 Tue 16:21]
  +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-10-14 Sun 10:31]
  +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-10-08 Mon 08:48]
  +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-09-29 Sat 18:50]
  +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-09-20 Thu 09:50]
  +  - Rescheduled from "[2019-02-05 Tue .+1m]" on [2018-09-14 Fri 07:10]
  
bisect says it was introduced in
af81211fdc01b64449179bcdb77fb1c8ecb3fb94.

cheers all,
-cm