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

[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

[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

[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] recent org-mode changes: completion of repeated tasks cause rewriting of LOGBOOK 'Rescheduled from' entries

[cesar mena]

sorry. forgot to do a wide reply. fwd'ing the list.

-cm

--- Begin Message ---
hello daniel,

Daniel Ortmann  writes:

> I have a daily scheduled task with ...
>   SCHEDULED: <2019-01-11 Fri 07:50 .+1d>
>
> Recently, when I complete the task it not only moves the schedule to the next 
> day
> ... but it also rewrites all of the "Rescheduled from ..." entries in the 
> LOGBOOK.
>
> For example,
>   - Rescheduled from "[2019-01-11 Fri 07:50 .+1d]" on [2019-01-02 Wed 10:54]
>   - Rescheduled from "[2019-01-11 Fri 07:50 .+1d]" on [2018-12-31 Mon 11:50]
>   - Rescheduled from "[2019-01-11 Fri 07:50 .+1d]" on [2018-12-16 Sun 19:29]
>   - Rescheduled from "[2019-01-11 Fri 07:50 .+1d]" on [2018-12-03 Mon 10:49]
>  etc.

see this thread for the details:
http://lists.gnu.org/archive/html/emacs-orgmode/2019-01/msg00095.html

the short of it is that as of commit af81211fdc *any* inactive timestamp
within your "headline" that has a repeater will update when you mark the
task as DONE. it doesn't matter where that timestamp is.

> Those previous LOGBOOK entries no longer are available; they are wiped out by 
> new
> task completions.

i feel your pain. i hope you source control your org files. in the
meantime move the HEAD of your tree to some parent of af81211fdc or go
back to release_9.1.14.

good luck!

best,
-cm
--- End Message ---

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

[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

[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

[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

Re: [O] [bug] timed repeater shows up in wrong place

[cesar mena]

Nicolas Goaziou <m...@nicolasgoaziou.fr> writes:

> Hello,
>
> cesar mena <cm...@pobox.com> writes:
>
>> just making sure i'm getting this.
>>
>> in maint, if org-agenda-repeating-timestamp-show-all is nil we get
>> 72x. if it is non nil we get 2x. i'm in the 72x camp, so i don't need to
>> do anything.
>
> It is the opposite. 
>
>   `org-agenda-repeating-timestamp-show-all' t   -> 72x
>   `org-agenda-repeating-timestamp-show-all' nil -> 2x
>
> Default value is t, so you don't need to do anything.
>
>> when master comes around org-agenda-repeating-timestamp-show-all will go
>> away. to get 72x make sure that org-agenda-prefer-last-repeat is nil (?)
>
> 72x is the default behaviour in both maint and master. IOW
> `org-agenda-prefer-last-repeat' is nil by default in master.
>
> Regards,
>
> -- 
> Nicolas Goaziou

ok; this is perfect, whilst allowing users to keep the org 8 (2x)
behaviour.

thank you again nicolas.

-cm

Re: [O] [bug] timed repeater shows up in wrong place

[cesar mena]

hello,

Nicolas Goaziou  writes:

> Hello,
>
> Samuel Wales  writes:
>
>> thanks for the explanation.  the idea is that org 9 is using the
>> previously scheduled section as a complete list and that it did not
>> trigger on the first day and did on the second, and show-all nil in
>> org 9 does not refer to the scheduled section but only to the repeater
>> instances?
>
> I'm not sure to understand.
>
> Anyway, I pushed a change to maint that should solve the "72x vs. 2x"
> issue.

just making sure i'm getting this.

in maint, if org-agenda-repeating-timestamp-show-all is nil we get
72x. if it is non nil we get 2x. i'm in the 72x camp, so i don't need to
do anything.

when master comes around org-agenda-repeating-timestamp-show-all will go
away. to get 72x make sure that org-agenda-prefer-last-repeat is nil (?)

close?

thanks.

-cm


>>> I think we need a new variable, or to change this one, to have both
>>> behaviours possible. Suggestions (and docstrings) are welcome, we can
>>> implement them in master branch.
>>
>> the issues seem to be:
>>
>>   1] 72x vs. 2x
>>   2] duplicate in previously scheduled vs. not
>>
>> 1 is critical as it affects sorting.  perhaps
>> org-agenda-repeater-previously-scheduled-counts?  values could include
>> 'from-timestamp and 'from-previous-instance.
>> the latter is org 8.
>>
>> 2 is not critical.  i might be able to get used to having a complete
>> scheduled section.
>>
>> [dunno if previously-scheduled is a clear name.  i call it "nokori"
>> from the japanese for "remaining" merely to be unambiguous [i don't
>> care if it's in sumerian as long as it's unambiguous] but i don't
>> suppose that would work for most people.]
>
> I implemented the following variables in master:
>
> - `org-agenda-show-future-repeats'
> - `org-agenda-prefer-last-repeat'
>
> and removed `org-agenda-repeating-timestamp-show-all', which was
> ambiguous.
>
> Basically, IIUC, setting `org-agenda-show-future-repeats' to nil and
> `org-agenda-prefer-last-repeat' to t should reproduce exactly the
> behaviour of Org 8.
>
> Also, the combination of the two variables above gives more flexibility.
>
> Feedback welcome.
>
>
> Regards,
>
> -- 
> Nicolas Goaziou

Re: [O] [bug] timed repeater shows up in wrong place

[cesar mena]

Nicolas Goaziou <m...@nicolasgoaziou.fr> writes:

> Hello,
>
> cesar mena <cm...@pobox.com> writes:
>
>> hello guys,
>>
>> Samuel Wales <samolog...@gmail.com> writes:
>>
>>> by the way there is a bug in org 9 where org-scheduled face is
>>> erroneously used instead of org-scheduled-previously.
>>
>> as pointed out by samuel, commit
>> 69ec6258b65a5d317f0dcb275ec2d5a90f72f191 introduced a bug where a
>> previously scheduled item in the agenda does not get the
>> org-scheduled-previously face.
>
> Fixed. Thank you.
>
> Regards,
>
> -- 
> Nicolas Goaziou

confirmed. thanks.

best,
-cm

Re: [O] [bug] timed repeater shows up in wrong place

[cesar mena]

hello guys,

Samuel Wales  writes:

> by the way there is a bug in org 9 where org-scheduled face is
> erroneously used instead of org-scheduled-previously.

as pointed out by samuel, commit
69ec6258b65a5d317f0dcb275ec2d5a90f72f191 introduced a bug where a
previously scheduled item in the agenda does not get the
org-scheduled-previously face.

cheers,
-cm

Re: [O] [bug] timed repeater shows up in wrong place

[cesar mena]

hello list, nicolas, samuel,

On Mon, Nov 28, 2016 at 2:34 AM, Nicolas Goaziou  wrote:
> Hello,
>
> Samuel Wales  writes:
>
>> On 11/27/16, Nicolas Goaziou  wrote:
>>> I pushed a few more fixed in plain time-stamps and deadlines. Please
>>> report if you find anything suspicious.
>>
>> please try this:
>>
>>   SCHEDULED: <2016-09-17 Sat .+2d>
>>
>> emacs -Q, with a 2-day span and show-all nil.
>
> [...]
>
>> in org 9:
>>
>>   1] it shows on both days
>>   2] it shows 72x
>>
>> re 1, dunno if this was intended?
>
> It is.
>
> It shows first repeat. I assume you tested that yesterday, so you got
> the repeat for today. Since the repeat didn't trigger "today" (which is
> actually yesterday), it also displays a reminder for the scheduled item
> there.
>
> So, you have "72x" on "today" and a new repeat on the next day.
>
>> re 2, org 9 is trying to do its counting from the original timestamp
>> date.  i can understand the reasoning here, but do not want it for my
>> use case.
>
> It is, per 1-year old commit (3072cb28e8627066f465f1a4af85da88135d0549).
> Details are given here:
> .

right the rationale there is that it would be misleading to show 2x
when you really haven't "doneify" the task for more than 72 days. but,
alas, this is what org 8 does.

>> 72x gets buried.  it's a sudden pop up then a sudden drop off.  i want
>> a gradual bubbling down like in org 8.  a .+30d repeater should show
>> today, then tomorrow it should show 2x, then the next day it should
>> show 3x.
>>
>> org 8 is nicer for showing the fact that 2d ago you were reminded to
>> do it, and maybe did it but did not doneify or maybe were not able to
>> do it.  it bubbles down slowly.
>
> It's difficult to solve both problems. In any case, this will not happen
> in Org 9.0.
>
> I think the main problem is that you put too many things behind
> `org-agenda-repeating-timestamp-show-all'. Its name is misleading.
> I think we need a new variable, or to change this one, to have both
> behaviours possible. Suggestions (and docstrings) are welcome, we can
> implement them in master branch.

i generate a file for the year with "events", as samuel describes it,
when i need that kind of scheduling. this has the advantage of having
the "bubbling" effect, showing all the ones not marked done as
separate entries, and the ability to have notes per event. i'm
attaching the script i use to generate it ... i pipe the output into
an agenda accessible file. samuel maybe this is useful?


genevents
Description: Binary data

Re: [O] [bug] timed repeater shows up in wrong place

[cesar mena]

Samuel Wales <samolog...@gmail.com> writes:

> On 11/10/16, cesar mena <cm...@pobox.com> wrote:
>> so the only thing i noticed is that your test case did not set
>> org-agenda-files for me. specifically your regexp did not pick up the
>> file (filename is test.org). i changed it as below, and it worked.
>
> thanks.
>
> i have documented my testcase for future purposes to be clear about this.
>
> i did find one thing:
>
> org-agenda-repeating-timestamp-show-all has changed its
> meaning in org 9.
>
> when nil
>   my version of org 8 (and previous versions of org) will show the
> task in the grid
>   org 9 will not show the task in the grid
>
> note that this is when nil.
>
> is anything known about this change?

i am not aware of any.  try bisecting your tree. if it works for 8, but
not 9 you will eventually find the changeset.

Re: [O] helm-org-clock for using helm rather than orgmode select menu

[cesar mena]

"Tory S. Anderson"  writes:

> Are you sure? In my org 9.0 box, I still see a non-helm 
> "org-agenda" menu (one of the things I haven't gotten around to 
> helm-ifying yet). 

sorry, i mis-understood. this is only for things that use the
completion-read interface.


[...]

Re: [O] helm-org-clock for using helm rather than orgmode select menu

[cesar mena]

"Tory S. Anderson"  writes:

> I've made the following adjustment to org-clock-select-task that 
> allows you to (optionally) use helm to select, rather than 
> orgmode's built in screens. Eventually I'd like to see all orgmode 
> commands have the option of using helm rather than their custom 
> screens, as Helm is a great package. Until then, hopefully you can 
> find this useful or give useful suggestions.
>
> https://github.com/WorldsEndless/helm-org-clock

from the 9.0 changelog it looks like this was done?

 Remove all options related to ido or iswitchb

 This includes org-completion-use-iswitchb and
 org-completion-use-ido. Instead Org uses regular functions, e.g.,
 completion-read so as to let those libraries operate.

best,
- cm

Re: [O] how do you select tasks for clocking in?

[cesar mena]

Alan Schmitt  writes:

> [ Unknown signature status ]
> Hello,
>
> I'm trying to consistently use org-clock, but I'm encountering a big
> obstacle: task selection. I very often do not start working on a task as
> I'm in my main org file, so to clock it in I would first need to find it
> there, which is a big enough hurdle for me not to do it. Ideally, I
> would like to have a global key that I hit that let me choose with
> ivy/helm/ido one task from my agenda files and start clocking it.
>
> Does such a thing exist? If not, how do you start clocking in?
>
> Thanks,
>
> Alan

this http://doc.norang.ca/org-mode.html#Clocking is a different approach
using a default task and clocking history.  it might be helpful. 

-cm

Re: [O] org-agenda-scheduled-leaders and repeating tasks

[cesar mena]

On Wed, Oct 28, 2015 at 9:52 AM, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote:
> cesar mena <cm...@pobox.com> writes:
>
>> however the face is now `org-scheduled-today, as opposed to
>> `org-scheduled-previously, and the agenda sorting is wrong. instead of
>> bubbling to the top (since it is so late) it is staying within the
>> "scheduled today" range.
>
> I committed another attempt in master. Thank you.
>
> Regards,

hi nicolas, list,

everything works. thank you so much.

nice side-effect: the behaviour now allows one to use non "."
repeaters as a poor man's habit mode since the Sched.x header line
will inform one how many cycles are behind.  it's also much clearer.
before on marking as done, the item will just be automatically
rescheduled again with no feedback as to why.

thanks again.

-cm

Re: [O] org-agenda-scheduled-leaders and repeating tasks

[cesar mena]

hi again nicolas,

sorry. i made a mistake updating my tree.

i'm quite certain i'm on master now "org-version: 8.3.2
(release_8.3.2-219-g770671)" and the repeater resets itself again.

so presently i have a task that looks like this:

** TODO some task
   SCHEDULED: <2015-08-24 Mon ++1w>

and in the agenda it shows up as:

  Scheduled:  TODO some task

best,
-cm





On Mon, Oct 26, 2015 at 9:13 AM, cesar mena <cm...@pobox.com> wrote:
> hello guys,
>
> so far so good for me.
>
> thanks nicolas and matt.
>
> -cm
>
> On Sun, Oct 25, 2015 at 1:24 PM, Nicolas Goaziou <m...@nicolasgoaziou.fr> 
> wrote:
>> Nicolas Goaziou <m...@nicolasgoaziou.fr> writes:
>>
>>> Matt Lundin <m...@imapmail.org> writes:
>>>
>>>> In short, org-habit seems to want a + notation for the purposes of the
>>>> agenda display and a .+ notation for the purposes of resetting the
>>>> timestamp. What is the best solution?
>>>
>>> Still looking for it.
>>>
>>> Meanwhile, I reverted the opinionated change in
>>> a427098b57c747ecc76feb0593f32922a1e12f67.
>>
>> Another take on this in 3072cb28e8627066f465f1a4af85da88135d0549.

Re: [O] org-agenda-scheduled-leaders and repeating tasks

[cesar mena]

me again :)

the calculation is correct.

however the face is now `org-scheduled-today, as opposed to
`org-scheduled-previously, and the agenda sorting is wrong. instead of
bubbling to the top (since it is so late) it is staying within the
"scheduled today" range.


best,
-cm


On Mon, Oct 26, 2015 at 4:31 PM, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote:
> cesar mena <cm...@pobox.com> writes:
>
>> sorry. i made a mistake updating my tree.
>>
>> i'm quite certain i'm on master now "org-version: 8.3.2
>> (release_8.3.2-219-g770671)" and the repeater resets itself again.
>>
>> so presently i have a task that looks like this:
>>
>> ** TODO some task
>>SCHEDULED: <2015-08-24 Mon ++1w>
>>
>> and in the agenda it shows up as:
>>
>>   Scheduled:  TODO some task
>
> Hopefully fixed, this time. Thank you.
>
> Regards,

Re: [O] org-agenda-scheduled-leaders and repeating tasks

[cesar mena]

hi samuel,

yes i suspect this is why it hasn't been reported in years.

what say you nicolas?

-cm

On Mon, Oct 26, 2015 at 4:23 PM, Samuel Wales  wrote:
> fwiw, i am one who is so [disorganized?] that the old behavior is
> preferred.  if something is a 6m repeater, and i ignore it for 6m,
> it's actually useful to be reminded after another repeat.  perhaps
> more normal people would understand 1w.  no matter how much i "should"
> mootify it or take it off the list or do it, this "bug" has proved
> useful in practice.
>
> i don't claim to represent hordes of disorganized people, but there you have 
> it.

Re: [O] org-agenda-scheduled-leaders and repeating tasks

[cesar mena]

hello guys,

so far so good for me.

thanks nicolas and matt.

-cm

On Sun, Oct 25, 2015 at 1:24 PM, Nicolas Goaziou  wrote:
> Nicolas Goaziou  writes:
>
>> Matt Lundin  writes:
>>
>>> In short, org-habit seems to want a + notation for the purposes of the
>>> agenda display and a .+ notation for the purposes of resetting the
>>> timestamp. What is the best solution?
>>
>> Still looking for it.
>>
>> Meanwhile, I reverted the opinionated change in
>> a427098b57c747ecc76feb0593f32922a1e12f67.
>
> Another take on this in 3072cb28e8627066f465f1a4af85da88135d0549.

Re: [O] org-agenda-scheduled-leaders and repeating tasks

[cesar mena]

Hi Nicolas,

Thanks!  Your approach works for me, buy won't it trip up someone who is
used to the current behaviour?

Cheers
-cm
Hello,

cesar mena <cm...@pobox.com> writes:

> i think what i am trying to say is best shown with an example.
>
> so let's say that today is oct 13th.
>
> the task
> ** TODO check smoke alarm
>SCHEDULED: <2015-10-04 Sun .+10d>
>
> shows up in the agenda as:
>
> Sched.10x:  TODO check smoke alarm
>
> however, had the task been scheduled a day before (or if today was oct
14th):
>
>  ** TODO check smoke alarm
>SCHEDULED: <2015-10-03 Sat .+10d>
>
> it would show up in the agenda as:
>
> Scheduled:  TODO check smoke alarm
>
> that is to say, the marker that indicates it is overdue is gone.  for
> some cases, like checking the smoke alarm, i don't want the "Sched.?x"
> to reset.
>
> ie, Sched.11x:  TODO check smoke alarm
>
> i tracked this down to the function org-time-string-to-absolute.  when
> rendering the agenda it gets called with today as its DAYNR argument,
> which causes "org-closest-date" to return "today" for the case of
> repeating timestamps.
>
> i can understand why it is done this way, and i find it useful.
> however for some tasks, i'd rather the counter not reset lest i miss
> something for longer than i should have (the smoke alarm case for
> example).

I fixed the issue with a rather opinionated change.
`org-agenda-repeating-timestamp-show-all' no longer applies on ".+" and
"++" repeaters.

Thank you.


Regards,

--
Nicolas Goaziou

[O] org-agenda-scheduled-leaders and repeating tasks

[cesar mena]

hello everyone,

i think what i am trying to say is best shown with an example.

so let's say that today is oct 13th.

the task
** TODO check smoke alarm
   SCHEDULED: <2015-10-04 Sun .+10d>

shows up in the agenda as:

Sched.10x:  TODO check smoke alarm

however, had the task been scheduled a day before (or if today was oct 14th):

 ** TODO check smoke alarm
   SCHEDULED: <2015-10-03 Sat .+10d>

it would show up in the agenda as:

Scheduled:  TODO check smoke alarm

that is to say, the marker that indicates it is overdue is gone.  for
some cases, like checking the smoke alarm, i don't want the "Sched.?x"
to reset.

ie, Sched.11x:  TODO check smoke alarm

i tracked this down to the function org-time-string-to-absolute.  when
rendering the agenda it gets called with today as its DAYNR argument,
which causes "org-closest-date" to return "today" for the case of
repeating timestamps.

i can understand why it is done this way, and i find it useful.
however for some tasks, i'd rather the counter not reset lest i miss
something for longer than i should have (the smoke alarm case for
example).

i patched my version of org to do this (release_8.2.10); but i did it
by not calling org-closest-date in the case of repeating timestamps
with the effect they all act this way. to do this properly i'd imagine
we would need another identifier in the timestamp(?)

i am willing to do the work to contribute the proper patches and
update the doc if people are interested.

... or is there another way of doing this? :)

thank you kindly for reading!

- cesar

Re: [O] Do you like to have your TODOs at the same headline level?

[cesar mena]

i do the same; 4 char states - with box around them

(setq org-todo-keyword-faces
  '(("TODO" . (:foreground "pink"
   :box (:line-width 1 :style none)))
("NEXT" . (:foreground "green"
   :box (:line-width 1 :style none)))
("WAIT" . (:foreground "yellow"
   :box (:line-width 1 :style none)))
("HOLD" . (:foreground "light blue"
   :box (:line-width 1 :style none)))
("CNC!" . (:foreground "gray"
   :box (:line-width 1 :style none)))
("DONE" . (:box (:line-width 1 :style none)

-cm

On Wed, Aug 26, 2015 at 3:00 PM, Sebastien Vauban
 wrote:
> dbo...@mmm.com (J. David Boyd) writes:
>> Sebastien Vauban  writes:
>>> William Denton  writes:
 I'm trying to spend more time in a sparse tree view where I just see
 TODOs (C-c / t).  I didn't like having the TODOs at different levels
 of indentation, though.  I prefer seeing them all lined up, so
 I moved them all to be fourth-level headline.  It's visually
 pleasing, and I don't care if a second-level headline has
 a fourth-level child without a third-level one.

 Do other people do this?
>>>
>>> No, and I don't think that's sane.  It would be logical to expect
>>> problems at export time (to LaTeX, among others) and in Org-lint.
>>>
>>> I try to put all the tasks at the 2nd level, the 1st level being
>>> reserved for big sections such as "Administration", "Tasks", "Team",
>>> etc.
>>>
>>> I'm very rigorous about expecting that all my "project management"
>>> documents can be exported (without loosing subtrees or generating error)
>>> to HTML (as the very first goal) and to LaTeX (as the second one).
>>>
>>> OTOH, I don't deny your wish to get things aligned; that's why I've
>>> opted to 4-char todo states only!
>>
>> 4-char todo states?  How about a list? I can't picture how to
>> abbreviate some things...
>
> Sure. Here it is:
>
> - TODO :: Open, not (yet) started.
> - STRT :: In progress, working on, doing.
> - WAIT :: On hold, assigned, feedback.
> - SDAY :: Someday, maybe, perhaps, wish.
> - DONE :: Completed, closed, resolved.
> - CANX :: Wontfix, rejected.
>
> The only exception, but that's on purpose is "NEW" for things going to
> the CollectBox.
>
> Best regards,
>   Seb
>
> --
> Sebastien Vauban
>
>

Re: [O] Maintainer change on May 1st

[cesar mena]

hi guys,

are we going to get the just when i thought i was out they pull me back
in video?

:)

-cesar



On Mon, Apr 7, 2014 at 11:24 AM, Carsten Dominik
carsten.domi...@gmail.comwrote:

 Hi everyone,

 per May 1st, I would like to swing the official maintainership back to
 Bastien, who has agreed to this change.  This really only means putting
 facts onto websites, because Bastien has in effect been doing this job all
 the time - I have unfortunately been unable to make time free to contribute
 here in any meaningful way, for which I apologise. I trust that an
 overwhelming majority of you will have not objections to this step

 Regards

 - Carsten