Hi, I have a problem with my appt.el replacement I develop. When debugging, I found that `org-agenda-get-timestamps' does, depending on the position of the SCHEDULED spec, do return a timestamp when an entry is formatted like this: ** APPT 10:40 Xyz :PROPERTIES: :ID: 1d313f9a-3044-4c23-9278-422646ec9063 :END: SCHEDULED: <2020-11-08 So +1d> but not when formatted like this: ** APPT 10:40 Xyz SCHEDULED: <2020-11-08 So +1d> :PROPERTIES: :ID: 1d313f9a-3044-4c23-9278-422646ec9063 :END: although the latter form is, AFAICT, recommended, and at least it's what I get when creating ids automatically with (org-id-get-create). No timestamp, and my appointments don't work (bad). Has anybody any insight into this matter? TIA, Michael.
Michael Heerdegen writes: > When debugging, I found that `org-agenda-get-timestamps' does, depending > on the position of the SCHEDULED spec, do return a timestamp when an > entry is formatted like this: > > ** APPT 10:40 Xyz > :PROPERTIES: > :ID: 1d313f9a-3044-4c23-9278-422646ec9063 > :END: > SCHEDULED: <2020-11-08 So +1d> To be valid, the SCHEDULED spec should be immediately following the headline. So this is just a timestamp... > but not when formatted like this: > > ** APPT 10:40 Xyz > SCHEDULED: <2020-11-08 So +1d> > :PROPERTIES: > :ID: 1d313f9a-3044-4c23-9278-422646ec9063 > :END: > > although the latter form is, AFAICT, recommended, and at least it's what > I get when creating ids automatically with (org-id-get-create). ...while this is a valid scheduled heading. > No timestamp, and my appointments don't work (bad). > > Has anybody any insight into this matter? I haven't looked too closely, but at first glance org-agenda-get-timestamps not detecting the second entry seems expected. org-agenda-get-timestamps has a comment that says "[s]kip date ranges, scheduled and deadlines, which are handled specially". Still without looking closely, I'd guess that the "handled specially" is referring to org-agenda-get-scheduled and org-agenda-get-deadlines.
Kyle Meyer <kyle@kyleam.com> writes:
> > but not when formatted like this:
> >
> > ** APPT 10:40 Xyz
> > SCHEDULED: <2020-11-08 So +1d>
> > :PROPERTIES:
> > :ID: 1d313f9a-3044-4c23-9278-422646ec9063
> > :END:
> >
> > although the latter form is, AFAICT, recommended, and at least it's what
> > I get when creating ids automatically with (org-id-get-create).
>
> ...while this is a valid scheduled heading.
Hmm, seems my code has come to the same conclusion and magically started
working, without any change, AFAICT. Strange, dunno how, but your
answer somehow helped. Quantum physics, probably. I hope it remains
so...
Thanks,
Michael.