From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard G Riley Subject: Re: resheduling from agenda buffer Date: Fri, 28 Sep 2007 18:17:28 +0200 Message-ID: <8dlkaqbw87.fsf@dev.shamrockirishbar.com> References: <87r6kix1fl.fsf@bzg.ath.cx> <52D89C75FEE9444E8D9C016E3730098306CE40@chsa1036.share.beluni.net> <87zlz6db6b.fsf@bzg.ath.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IbIX2-0004v5-AR for emacs-orgmode@gnu.org; Fri, 28 Sep 2007 12:17:36 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IbIX0-0004ue-1b for emacs-orgmode@gnu.org; Fri, 28 Sep 2007 12:17:35 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IbIWz-0004ub-TS for emacs-orgmode@gnu.org; Fri, 28 Sep 2007 12:17:33 -0400 Received: from ug-out-1314.google.com ([66.249.92.170]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IbIWz-00068E-KQ for emacs-orgmode@gnu.org; Fri, 28 Sep 2007 12:17:33 -0400 Received: by ug-out-1314.google.com with SMTP id m4so1773235uge for ; Fri, 28 Sep 2007 09:17:32 -0700 (PDT) In-Reply-To: <87zlz6db6b.fsf@bzg.ath.cx> (Bastien's message of "Fri\, 28 Sep 2007 18\:09\:16 +0200") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Bastien Cc: emacs-orgmode@gnu.org Bastien writes: > "Egli Christian (KIRO 41)" writes: > >> I think the reason is the principle of least surprise. > > Agreed. That's also why rescheduling should perhaps leave some > persistent warning in the agenda buffer (as S-left/right does). > I guess it would solve the issue Richard was concerned about. Most 100% certainly. See the other reply. The S- functionality is spot on. As a noob I believe I am more likely to spot these inconsistencies that established users. The other reply might have been private so I include it below: ,---- | While I can understand that, it certainly surprises the user to try and | reschedule a task that isn't really there. I would suggest that the only | sensible and usable and consistent thing to do is to mark it as changed | like with the S- .. in this case it hilites the entry as | changed but you can continue to work on it. And then refresh (r) | obviously moves all tasks to their correct positions while leaving the | cursor at the current/next line. | | The functionality for S- is perfect. `----