From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Andrew M. Nuxoll" Subject: Re: Still Wishing for Snooze Date: Fri, 25 Jan 2013 11:30:30 -0800 Message-ID: <5102DD56.3050907@up.edu> References: <50FD86D4.8080105@up.edu> <877gn410o4.fsf@bzg.ath.cx> <51018250.2050404@up.edu> <878v7i2p6k.fsf@bzg.ath.cx> <5101BB9A.5000505@up.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([208.118.235.92]:45729) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tyozg-000718-JU for emacs-orgmode@gnu.org; Fri, 25 Jan 2013 14:31:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tyozd-00057c-4w for emacs-orgmode@gnu.org; Fri, 25 Jan 2013 14:31:20 -0500 Received: from esa2.up.iphmx.com ([68.232.135.153]:53245) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tyozc-00057D-VA for emacs-orgmode@gnu.org; Fri, 25 Jan 2013 14:31:17 -0500 In-Reply-To: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Michael Brand Cc: Org Mode That looks like a delay period on a SCHEDULED item would work very well for me. I can see the positive delay period being useful to me as well. This does look like it would be more difficult to implement because it's a subtle change to existing code rather than something more modular. :AMN: On 01/25/2013 03:10 AM, Michael Brand wrote: > Hi Andrew > > On Thu, Jan 24, 2013 at 11:54 PM, Andrew M. Nuxoll wrote: >> Here an example scenario that illustrates my problem: Say, at the end of >> each week I need to sit down and generate a report on my progress to send to >> the boss. So I have recurring, weekly TODO entry on Friday morning. Well, >> one week the report is delayed because a coworker was ill and couldn't send >> me the data I needed on time. So, I have to delay that TODO entry until >> Monday *just this one time.* I need to get it off my agenda for the day but >> I don't want to mark is as completed because it's not. >> >> Right now the only way to do that is to mark it as completed anyway but make >> a one-time copy of the TODO item with the new scheduled date. The problem >> is that I have roughly thirty TODO items per day and, on any given day, I >> need to delay about 10-20% of them for various reasons. (It's the nature of >> my job though I don't think it's that unusual.) So making a copy of a TODO >> item each time is inconvenient because I end up with dozens of copies >> floating about. >> >> Furthermore, a delayed TODO item should have more urgency since it's been >> delayed. But creating a copy means i can't do that. When Monday rolls >> around and it's time to prepare that report it shows up in green text like >> this in my agenda: >> Scheduled: TODO [#B] Prepare TPS Report >> >> but I want it to be in red text like this: >> Sched. 4x: TODO [#B] Prepare TPS Report >> >> This is why I'm looking for a distinct "snooze" or "delay" functionality. I >> want a TODO item to disappear from the agenda until a specified date and >> then reappear again waiting to be done with all the urgency associated with >> that delay. > Let me only suggest an idea to deal with this, item-based: When the > DEADLINE “warning period” would be generalized to allow positive > numbers then it would extend to a “warning and delay period”. Starting > with: > > * TODO [#B] Verify login to the virtual machines > DEADLINE: <2013-01-22 Tue +1w -0d> > > It could be delayed to <2013-01-24 Thu> which means two days later by > changing the “warning and delay period” to 2d: > > * TODO [#B] Verify login to the virtual machines > DEADLINE: <2013-01-22 Tue +1w 2d> > > This would not show up in the agenda until <2013-01-24 Thu>. At that > date it would be shown with the desirable “In -2 d.:” for overdue to > get the higher priority. When set to done it would become: > > * TODO [#B] Verify login to the virtual machines > DEADLINE: <2013-01-29 Tue +1w -0d> > > Note the change from 2d to -0d: It is important that when the date > repeats and has a positive warning period aka delay period then it > must be reset to -0d. Otherwise undesirable suprises are guaranteed. > > The same “warning and delay period” could also be allowed for > SCHEDULED, mainly usable with a positive range for a delay. Probably > what you would prefer over DEADLINE for your use case. I would even > allow negative numbers for a warning for SCHEDULED, with a default > warning period of -0d to reflect current behavior. > > Michael -- Andrew M. Nuxoll Phone: 503-943-7688 Asst Professor of Computer Science Fax: 503-943-7316 University of Portland - MSC #145 Email: nuxoll@up.edu 5000 N. Willamette Blvd Web: http://faculty.up.edu/nuxoll Portland, OR 97203-5798 Office: Shiley Hall Rm 217