emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Trevor Murphy <trevor.m.murphy@gmail.com>
To: emacs-orgmode@gnu.org
Subject: 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	[thread overview]
Message-ID: <87iojuikvq.fsf@gmail.com> (raw)

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	other threads:[~2014-10-08 16:31 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=87iojuikvq.fsf@gmail.com \
    --to=trevor.m.murphy@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    /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).