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

[Samuel Wales]

hi nicolas,

thanks for your reply.

some things that i expected from org x<=8 to occur are not
occurring on the dates i expected or in the time grid.

so i wonder:

  1) what changed in repeater agenda behavior from org 8 to
     org 9
     - at least one and possibly several
  2) where in the code the changes are so i can revert it in
     git until this is fixed.

of course, this might in principle be explained by a single
change (see below).

On 11/13/16, Nicolas Goaziou <address@hidden> wrote:
> I mean that a variable ignoring all repeaters in agenda is useful. It
> means that, e.g.,
>
>   <2016-11-13 Sun +1d>
>
> is seen as
>
>   <2016-11-13 Sun>
>
> To put it differently, this would ignore repeaters until the task is
> marked as done, which is repeaters original purpose.

ok, so you can see a need for a setting that implements
"show NONE except the timestamp date".  i.e. remove the
repeater aspect of repeaters.

i don't need such a feature, but it seems useful.

> However `org-agenda-repeating-timestamp-show-all' seems to
> do something different.

yes, or at least different org 8 vs. org 9.

...

it is with .+ that i am noticing the anomalies in org 9.

i almost always use .+, so i am much more concerned about
them in my own case, not + or ++.

i was thinking of the mce i posted, but you were talking in
general terms.

>
> AFAIU, a nil `org-agenda-repeating-timestamp-show-all' means that
> nothing will appear on <2016-11-09 Wed>, but the task will be displayed
> on <2016-11-15 Tue>, as if it was automatically marked as done without
> my consent. Odd.

so your understanding is that a repeat indicates having gone
through the done state if nil?

i think of it ALSO as a reminder, without cluttering up
every date.

>
> Note that I could understand the use for that. But there is worse:
>
>    <2016-11-09 Wed .+3d>
>
> In this case, I cannot possibly guess when the next repeat is going to
> show, since it depends on the date at which the task is done. As

it is STILL also a reminder that it needs doing at around
this frequency.

> a consequence, treating the above as <2016-11-09 Wed +3d> is just plain
> wrong IMO. Every repeat displayed in the agenda could be inaccurate.

iirc you indicated in an old email that you didn't want the
variable to apply to .+ or ++ .

i indicated to you that i found the usual org behavior (org
8 and previous) to be extremely useful.  i believe the op,
for whom you made the change, also queried whether the
change should be optional.

the release notes for org 9 did not indicate any change, but
we are seeing changes from org 8 to org 9.

so it seems possible that you made the change and that it
went through to org 9 and that that is what we are
witnessing.

does that sound possible to you?  which git delta do you
think is relevant?

===

i don't think the only purpose of an occurrence is to
indicate having gone through the done state.

===

i will try to explain.  i also tried to explain it in the
old email.  i hope i don't make a mistake.  i am fogged and
limited in typing.

i prefer the setting of showing today or on an upcoming date
(org 8 nil) to the extreme settings of showing only the
timestamp date or all (your nil or t).  this gives me just
enough information but not too much.

there is valuable information in the repeater interval.  it
says "this is about the frequency this should be done".  it
doesn't have to be exact.

===

sometimes people forget to doneify the previous instance.
sometimes they don't even DO the previous instance, but
still want reminding.

showing the repeater not on every date but on today or the
nearest into the future says "popping up again at about the
same frequency -- either you forgot to doneify or you did
not do it".

org 8 reminded me "you went through ANOTHER cycle without
doneifying this .+!".  even in the time grid if it is timed.

===

it's a reminder frequency that scales with the repeater
interval.  that's what i need.

===

another factor is appt, which activates when something is in
today's time grid.  org 9 breaks that.  if i did not do a
task. i don't get reminded by appt in org 9.

===

bubbling down in a sched nx line is not enough.  that
becomes decreasingly looked at.  your use case is different.
you probably always look at all of your sched. nx.

things that bubble down in sched. nx in org 9 could mean
"long repeater interval" OR "you didn't doneify it".  to me
those are totally unrelated things.

in org 8 if they mean the latter, i know that i will be
reminded in a more visible place.

===

i am incapable of doing many things, but i need .+
semantics.  i want to be reminded, but not on every
occurrence, just today or nearest into future.

the "pop up again, then bubble down, then pop up again"
behavior is exactly what i need.  then i doneify and it does
not show until .+nd.

so if possible, i'd like this customizable back to org 8
behavior.  it's throwing me off quite a bit and i no longer
can trust the repeaters in the agenda.

>
>>> makes little sense, in particular with schedules or deadlines.
>>
>> i don't get why.
>
> Because schedules and deadlines are already repeated, somehow, in the
> agenda. Today being <2016-11-13 Sun>, let's consider a task, not done

i disagree with this reasoning.  see below.

> yet, with the following SCHEDULED time:
>
>   <2016-11-09 Wed +1d>
>
> I will get "Sched.4x". Yet closest repeat is today, so a nil
> `org-agenda-repeating-timestamp-show-all' dumbly displays the task
> without the "Sched.4x".
>
> I lost the information the task started 4 days ago. If I mark it as
> done, it still appears on today, without any feedback telling me it is
> a new task that started 3 days ago, this time.

but in org 9 i now lose the information about the frequency
of the interval.  i lost the reminders.

the traditional org behavior is a feature for me, not a bug.

unlike you, i don't care as much about the number of days
past due it is.  i get to see that when not near a repeater
occurrence.  and i can find out by looking at the timestamp.

> Why would I want that?
>
>>> So, what is wrong with `org-agenda-repeating-timestamp-show-all' default
>>> value?
>>
>> t you mean?  if i am showing today and tomorrow, or the whole week, i
>> don't want to see the repeater show up on every day.
>
> OK, if you mainly use "+1d" repeaters, it can be a bit verbose. But then
> again, if `org-agenda-repeating-timestamp-show-all' ignored the repeat
> altogether, it wouldn't fill up the agenda.

i use all sorts of .+ repeaters, not just .+1d.

nil would bubble down where i would not distinguish it from
long repeater interval.

my planning ability is broken, but i think org is also for
people with bad planning ability.

>
>> i just want it to show up today.  then i doneify it, and then i just
>> want it to show up tomorrow.  this is org 8 behavior for me.
>
> Again, if `org-agenda-repeating-timestamp-show-all' ignored the repeat
> part, you would still have this with schedules and deadlines, as
> exhibited above.

ignoring the repeat part means it gets buried in sched nx,
and i do not get reminded.

to me that's a regression.

>
> The only difference would be with plain time-stamps (no SCHEDULED nor
> DEADLINE keyword). In Org 8,
>
>   <2016-11-09 Wed +1d>
>
> appears today, no matter what "today" means for the agenda. Ignoring the
> repeater would not make it appear today unless today is <2016-11-09 Wed>,
> of course.
>
>> not sure we're communicating accurately though.
>
> It is difficult to communicate since the subject is not very well
> defined.

agreed, which is why i posted my rfc to try to clarify.

>
> In a nutshell, I fail to see any use for this variable for schedules and
> deadlines (except, perhaps, in the future part of the agenda). I also
> fail to see any use for it in conjunction with ".+" and "++" repeaters.
>
> I can be wrong, but I'd like to understand where.

i tried.  i might have made a mistake.  please go easy on me
if so.

i believe this is a difference of use case.

>
>
> Regards,
>
> --
> Nicolas Goaziou
>

samuel

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com

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

Denmark: free Karina Hansen NOW.
  UPDATE 2016-10: home, but not fully free