emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Nicolas Goaziou <n.goaziou@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Adding support for limits and exclusions to iCal recurring events
Date: Mon, 22 Jul 2013 16:56:25 +0200	[thread overview]
Message-ID: <87y58yprs6.fsf@toke.dk> (raw)
In-Reply-To: <87d2qa6cnh.fsf@gmail.com> (Nicolas Goaziou's message of "Mon, 22 Jul 2013 13:45:54 +0200")

[-- Attachment #1: Type: text/plain, Size: 3729 bytes --]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> I think EXCLUDE property is a good idea, but I may be renamed to
> ICALENDAR_EXCLUDE until it is also handled by Org Agenda, if it ever
> happens. It also needs to be documented in the manual.

Handling it in the agenda can be done by an exclusion function. I
currently have this in my org-agenda-skip-function-global (along with
another function to skip items after their END_DATE):

(defun thj/skip-excluded ()
  "Skip agenda items on dates in EXCLUDE property"
  (when (and (boundp 'date) date)
    (let ((excluded-string (thj/get-property "EXCLUDE"))
          exclusions)
      (when excluded-string
        (setq exclusions (mapcar
                          (lambda (ex-date-string)
                            (equal date (org-date-to-gregorian
                                          (org-parse-time-string ex-date-string))))
                          (split-string excluded-string ",")))
        (when (memq t exclusions)
          (org-end-of-subtree t))))))

(Should probably be updated to use the org native property extraction
mechanism, but this predates my discovery of that).

> On the other hand, I'm not sure about the END_DATE property. Couldn't
> DEADLINE be used for that matter? For example, `repeater-end-date'
> could be added to `org-icalendar-use-deadline' possible values. When
> this symbol belongs to variable's value and current entry has a
> deadline, any timestamps with a repeater get deadline's value as its
> END DATE property.
>
> What do you think?

Sure, that would work. Two possible issues spring to mind:

1. Is there any use cases where someone might want a deadline (in its
current use) along with an end date? Or some other conflict?

2. Will using the DEADLINE field make it harder to add exclusion from
the agenda? (I've never really used the deadline field, so don't know
what people normally use it for).

>> +(defun org-icalendar-zero-convert-timestamp (timestamp &optional format)
>> +  "Parse and format an org-formatted timestamp, zeroing the time component."
>> +  (let ((time (org-parse-time-string timestamp))
>> +	(fmt (or format "%Y%m%dT%H%M%SZ")))
>> +    (format-time-string fmt (encode-time 0 0 0 (nth 3 time) (nth 4 time) (nth 5 time)))))
>
> Can't `org-icalendar-convert-timestamp' be used instead?

It could, conceivably. However, I couldn't find any functions that would
parse a property string into the timestamp format expected by
org-icalendar-convert-timestamp, and since I would have to modify that
function quite a bit to make it do what I needed (print a UTC timestamp
string without taking time zones into account; only the date part is
used), I thought it would be easier to just create a new function.

The above interpretation of how UTC-strings are used in the exclude
parameter may be wrong, btw. Or rather, what I've done with END_DATE
here is interpret it purely as a date stamp and ignore the time part.
Looking at the iCal RFC (I realise now), that's probably not entirely
the right interpretation. However, having the "until" value include a
time might lead to unexpected results when END_DATE is set to something
close to a repetition value.

Calling it END_TIME (or, as above DEADLINE) might get this point across
and allow for an interpretation that includes the time part. Which would
mean it would make more sense to use the org-icalendar-convert-timestamp
at least for the end date. So, how do I parse that from a string? Or
perhaps that won't be an issue if using the DEADLINE field since that is
already parsed higher up in the chain?


*ahem*, sorry if the last part became a bit scatter-brained. :)

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

  reply	other threads:[~2013-07-22 14:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-07 15:55 Adding support for limits and exclusions to iCal recurring events Toke Høiland-Jørgensen
2013-07-22 11:45 ` Nicolas Goaziou
2013-07-22 14:56   ` Toke Høiland-Jørgensen [this message]
2013-07-24  8:38     ` Nicolas Goaziou
2013-07-24 16:01       ` Michael Brand
2013-07-24 17:25         ` Toke Høiland-Jørgensen
2013-07-27 21:11           ` Nicolas Goaziou
2013-07-27 22:16             ` Toke Høiland-Jørgensen
2013-07-24 18:23       ` David Rogers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y58yprs6.fsf@toke.dk \
    --to=toke@toke.dk \
    --cc=emacs-orgmode@gnu.org \
    --cc=n.goaziou@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).