emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[O] What is the deal with `org-agenda-skip-deadline-prewarning-if-schedu


From: Trevor Murphy
Subject: [O] What is the deal with `org-agenda-skip-deadline-prewarning-if-scheduled', 'pre-scheduled, and specific deadline lead times?
Date: Wed, 08 Oct 2014 12:31:05 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Hi, list! tl;dr given the setting alluded to in the subject line, I'm dissatisfied with the behavior of the following example (scheduling and
deadline timestrings use "today" as pseudocode):

* TODO check deadline skipping with specific lead time and 'pre-scheduled
DEADLINE: <today+2d -3d> SCHEDULED: <today+1d>

I would like to hack the code to change the behavior, but I'm concerned about breaking a zillion other things at the same time. Comments and suggestions
welcome.

Still with me?  Longer description below:

The documentation says
(http://orgmode.org/manual/Deadlines-and-scheduling.html):

You can specify a different lead time for warnings for specific deadlines using the following syntax. Here is an example with a warning period of 5 days =DEADLINE: <2004-02-29 Sun -5d>=. This warning is deactivated if the
task gets scheduled and you set
=org-agenda-skip-deadline-prewarning-if-scheduled= to =t=.

I have o-a-s-d-p-i-s set to 'pre-scheduled. Suppose today is Wednesday, 2014-10-08, and I create an agenda file "example.org" with the following
contents:

* TODO check deadline skipping with specific lead time
DEADLINE: <2014-10-10 Fri> SCHEDULED: <2014-10-09 Thu>

Then the deadline warning does not appear in today's agenda. This is what I want, and I think this is what I should expect with the 'pre-scheduled
setting.

However, if I use the following contents instead (note the specified warning
period):

* TODO check deadline skipping with specific lead time
DEADLINE: <2014-10-10 Fri -3d> SCHEDULED: <2014-10-09 Thu>

The deadline warning *reappears* in today's agenda. I think this is a bug. I think I've ruled out the personal-configuration sources of the behavior, and instead traced it to the following code in `org-agenda-get-deadlines':

 (setq wdays (if suppress-prewarning
(let ((org-deadline-warning-days suppress-prewarning))
                   (org-get-wdays s))
               (org-get-wdays s))
               ...)

In `org-agenda-get-deadlines', with o-a-s-d-p-i-s set to 'pre-scheduled, the code stores the gap between scheduling and deadline information in the local variable `suppress-prewarning'. As you can see in the citation above, o-a-g-d then let-binds the user option `org-deadline-warning-days' to match and calls `org-get-wdays' to figure out the appropriate amount of warning-day lead time.

But! Check out what `org-get-wdays' does with specific warning periods in the deadline timestring:

 (cond
   ...
((string-match "-\\([0-9]+\\)\\([hdwmy]\\)\\(\\'\\|>\\| \\)" ts)
   ;; lead time is specified.
   (floor (* (string-to-number (match-string 1 ts))
             (cdr (assoc (match-string 2 ts)
                         '(("d" . 1)    ("w" . 7)
                           ("m" . 30.4) ("y" . 365.25)
                           ("h" . 0.041667)))))))

`org-get-wdays' never checks `org-deadline-warning-days' in this branch, and so never gets a chance to see the `suppress-prewarning' information passed in
from `org-agenda-get-deadlines'.

At this point I'm stuck. I'd like to hack into `org-get-wdays' some code that says "Yes, there's a specific warning period. However, there's also some prewarning suppression going on, so we should take that into consideration." But I'd like to avoid changing the existing behavior for when there is no prewarning suppression and the specific warning period just happens to be
longer than the user option `org-deadline-warning-days'.

If you're still reading, thanks. Please let me know if you have any
suggestions, questions, or comments about what I'm trying to do.

--
Trevor Murphy
GnuPG Key: 0x83881C0A




reply via email to

[Prev in Thread] Current Thread [Next in Thread]