ox-icalendar: Filter todo-types

ox-icalendar: Filter todo-types

[Michaël Cadilhac]

I have a task that was recurring, which I KILLED a few weeks ago.  It
now looks like:

** KILLED Do the right thing
   SCHEDULED: <2023-07-14 Fri +1w>

ox-icalendar still exports it every week, because I have
'event-if-not-todo in org-icalendar-use-scheduled (which is the
behavior I want for some other headers).

BEGIN:VEVENT
DTSTAMP:20240622T163042Z
UID:SC-671b3d13-f985-472a-be33-b4eeb298f2cd
DTSTART;VALUE=DATE:20230714
DTEND;VALUE=DATE:20230715
RRULE:FREQ=WEEKLY;INTERVAL=1
SUMMARY:S: KILLED Do the right thing :
CATEGORIES:todos
END:VEVENT

I do not see any way to filter on todo-type in org-calendar-entry, the
relevant bit thereof reading:

            (and scheduled
                 (pcase todo-type
                   (`todo (or (memq 'event-if-todo-not-done use-scheduled)
                              (memq 'event-if-todo use-scheduled)))
                   (`done (memq 'event-if-todo use-scheduled))
                   (_ (memq 'event-if-not-todo use-scheduled)))
                 (org-icalendar--vevent
                  entry scheduled (concat "SC-" uid)
                  (concat scheduled-summary-prefix summary)
                  loc desc cat tz class)))

Would it be acceptable to add a variable to filter todo-types, e.g.,
with a variable org-icalendar-excluded-todo-types?  More generally,
one could think of introducing a variable:
   org-icalendar-entry-filter
which receives the ENTRY argument of org-icalendar-entry, and would
return non-nil if the entry is to be treated.  (This is basically what
I do using an advice.)

Cheers,
Michaël

Re: ox-icalendar: Filter todo-types

[Jack Kamm]

Michaël Cadilhac <michael@cadilhac.name> writes:

> I have a task that was recurring, which I KILLED a few weeks ago.  It
> now looks like:
>
> ** KILLED Do the right thing
>    SCHEDULED: <2023-07-14 Fri +1w>
>
> ox-icalendar still exports it every week, because I have
> 'event-if-not-todo in org-icalendar-use-scheduled (which is the
> behavior I want for some other headers).
>
> BEGIN:VEVENT
> DTSTAMP:20240622T163042Z
> UID:SC-671b3d13-f985-472a-be33-b4eeb298f2cd
> DTSTART;VALUE=DATE:20230714
> DTEND;VALUE=DATE:20230715
> RRULE:FREQ=WEEKLY;INTERVAL=1
> SUMMARY:S: KILLED Do the right thing :
> CATEGORIES:todos
> END:VEVENT
>
> Would it be acceptable to add a variable to filter todo-types, e.g.,
> with a variable org-icalendar-excluded-todo-types?  More generally,
> one could think of introducing a variable:
>    org-icalendar-entry-filter
> which receives the ENTRY argument of org-icalendar-entry, and would
> return non-nil if the entry is to be treated.  (This is basically what
> I do using an advice.)

I agree ox-icalendar should have an option to exclude certain
todo-keywords from export.

However I think the option should also be flexible to allow exporting
todo-keywords as different STATUS:

https://datatracker.ietf.org/doc/html/rfc5545#section-3.8.1.11

For example, in your case it might make more sense to export the task as
CANCELLED in iCalendar.

I think I'd rather have a customization option for this than a filter
function. That way, other Lisp programs that import ICS to Org (such as
org-caldav) could refer to this option to interoperate with ox-icalendar
for 2-way sync.

Perhaps we could have an option ox-icalendar-export-todo-keywords-as
which could determine whether a keyword should be exported, and if so
with what status, e.g.:

(defcustom ox-icalendar-export-todo-keywords-as
 '((no-export . ("SKIP"))
   (cancelled . ("KILLED" "CANCELLED"))
   (in-process . ("PROG"))))

By default, todo-keywords not in the list would be exported with status
"NEEDS-ACTION" or "COMPLETED", depending on whether the keyword is a
done state.

What do you think?

Re: ox-icalendar: Filter todo-types

[Ihor Radchenko]

Jack Kamm <jackkamm@gmail.com> writes:

> Perhaps we could have an option ox-icalendar-export-todo-keywords-as
> which could determine whether a keyword should be exported, and if so
> with what status, e.g.:
>
> (defcustom ox-icalendar-export-todo-keywords-as
>  '((no-export . ("SKIP"))
>    (cancelled . ("KILLED" "CANCELLED"))
>    (in-process . ("PROG"))))

Maybe we can expand the allowed values of `org-icalendar-include-todo' instead?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: ox-icalendar: Filter todo-types

[Michaël Cadilhac]

On Sun, Jun 23, 2024 at 1:25 PM Ihor Radchenko <yantar92@posteo.net> wrote:
>
> Jack Kamm <jackkamm@gmail.com> writes:
>
> > Perhaps we could have an option ox-icalendar-export-todo-keywords-as
> > which could determine whether a keyword should be exported, and if so
> > with what status, e.g.:
> >
> > (defcustom ox-icalendar-export-todo-keywords-as
> >  '((no-export . ("SKIP"))
> >    (cancelled . ("KILLED" "CANCELLED"))
> >    (in-process . ("PROG"))))

@Jack: That sounds good, and I'd defer to your knowledge of the RFC!

> Maybe we can expand the allowed values of `org-icalendar-include-todo' instead?

I don't think this is the purpose of `include-todo', which seems to be
specific to VTODO vs VEVENT.  Do you have something in mind that
combines that feature with STATUS?

Re: ox-icalendar: Filter todo-types

[Ihor Radchenko]

Michaël Cadilhac <michael@cadilhac.name> writes:

>> > Perhaps we could have an option ox-icalendar-export-todo-keywords-as
>> > which could determine whether a keyword should be exported, and if so
>> > with what status, e.g.:
>> >
>> > (defcustom ox-icalendar-export-todo-keywords-as
>> >  '((no-export . ("SKIP"))
>> >    (cancelled . ("KILLED" "CANCELLED"))
>> >    (in-process . ("PROG"))))
> ...
>> Maybe we can expand the allowed values of `org-icalendar-include-todo' instead?
>
> I don't think this is the purpose of `include-todo', which seems to be
> specific to VTODO vs VEVENT.  Do you have something in mind that
> combines that feature with STATUS?

You are right that `org-icalendar-include-todo' is only affecting VTODO,
but not VEVENT.

My concern is mostly that "(no-export . ("SKIP"))" is somewhat similar
to `org-icalendar-include-todo' set to a list of todo keywords.  So, it
may be confused with VTODO-specific option.

Another concern is that we already have `org-export-with-tasks' where
you can specify which todo keywords should be exported and which
headings should be exported, according to their todo keyword. So,
"no-export" appears to unnecessary.

What is unique to icalendar exporter is the STATUS property. Having a
setting to set it according to todo keyword would indeed make sense.

However, after I looked at the RFC in more details now, I can see that
the values of STATUS property depend on the entry type:

       statvalue-event = "TENTATIVE"    ;Indicates event is tentative.
                       / "CONFIRMED"    ;Indicates event is definite.
                       / "CANCELLED"    ;Indicates event was cancelled.
       ;Status values for a "VEVENT"

       statvalue-todo  = "NEEDS-ACTION" ;Indicates to-do needs action.
                       / "COMPLETED"    ;Indicates to-do completed.
                       / "IN-PROCESS"   ;Indicates to-do in process of.
                       / "CANCELLED"    ;Indicates to-do was cancelled.
       ;Status values for "VTODO".

       statvalue-jour  = "DRAFT"        ;Indicates journal is draft.
                       / "FINAL"        ;Indicates journal is final.
                       / "CANCELLED"    ;Indicates journal is removed.
      ;Status values for "VJOURNAL".

Maybe we can introduce separate variables mapping todo keyword to status
depending on the entry type (VTODO vs. VEVENT; we do not export VJOURNAL)?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: ox-icalendar: Filter todo-types

[Jack Kamm]

Ihor Radchenko <yantar92@posteo.net> writes:

> Another concern is that we already have `org-export-with-tasks' where
> you can specify which todo keywords should be exported and which
> headings should be exported, according to their todo keyword. So,
> "no-export" appears to unnecessary.

That's a good point. Michael, does `org-export-with-tasks' suffice for
your original need/request?

> However, after I looked at the RFC in more details now, I can see that
> the values of STATUS property depend on the entry type:
>
>        statvalue-event = "TENTATIVE"    ;Indicates event is tentative.
>                        / "CONFIRMED"    ;Indicates event is definite.
>                        / "CANCELLED"    ;Indicates event was cancelled.
>        ;Status values for a "VEVENT"
>
>        statvalue-todo  = "NEEDS-ACTION" ;Indicates to-do needs action.
>                        / "COMPLETED"    ;Indicates to-do completed.
>                        / "IN-PROCESS"   ;Indicates to-do in process of.
>                        / "CANCELLED"    ;Indicates to-do was cancelled.
>        ;Status values for "VTODO".
>
>        statvalue-jour  = "DRAFT"        ;Indicates journal is draft.
>                        / "FINAL"        ;Indicates journal is final.
>                        / "CANCELLED"    ;Indicates journal is removed.
>       ;Status values for "VJOURNAL".
>
> Maybe we can introduce separate variables mapping todo keyword to status
> depending on the entry type (VTODO vs. VEVENT; we do not export VJOURNAL)?

Sure, but we should also consider the STATUS for VEVENTs created from
non-TODO entries.

Perhaps these variables could map tags as well as todo keywords to
status? E.g., in the following:

(setq org-icalendar-event-status-map
      '((cancelled . ("KILLED" "cancelled"))))

Then any VEVENT created from entries whose todo-keyword or tag matches
the above would have STATUS set to CANCELLED. For example, both of the
following entries would contain VEVENTs exported as such:

* An event that was cancelled :cancelled:

  A non-todo entry with active timestamp <2024-06-23>.
  It will be exported with STATUS as CANCELLED.

* KILLED A todo that was cancelled
  SCHEDULED: <2024-06-22>

  This todo entry has both a scheduling timestamp as well as an active
  timestamp <2024-06-23>, and may create both VEVENT and VTODO. Any
  VEVENTs created will have STATUS as CANCELLED, due to "KILLED" being
  in org-icalendar-event-status-map.  Any VTODO created will have STATUS
  set according to org-icalendar-todo-status-map instead.

Re: ox-icalendar: Filter todo-types

[Ihor Radchenko]

Jack Kamm <jackkamm@gmail.com> writes:

> Perhaps these variables could map tags as well as todo keywords to
> status? E.g., in the following:
>
> (setq org-icalendar-event-status-map
>       '((cancelled . ("KILLED" "cancelled"))))

Then, may as well just map generalized property:

'((canceled . (("TODO" . "KILLED") ("TAGS" . "cancelled") ("PROPERTY" . "VALUE"))))

We might also allow setting something like

* An event that was canceled
:PROPERTIES:
:ICALENDAR_VEVENT_STATUS: canceled
:END:

  A non-todo entry with active timestamp <2024-06-23>.
  It will be exported with STATUS as CANCELLED.

Or, if we want to go even further, may allow TAGS-matcher
syntax/arbitrary function as the criterion.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>