From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bastien Subject: Re: org-sort-agenda-notime-is-late is mishandled in org-cmp-ts Date: Fri, 03 Jan 2014 16:02:12 +0100 Message-ID: <87iou1cdmz.fsf@bzg.ath.cx> References: Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:55662) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vz6GV-0006R7-CT for emacs-orgmode@gnu.org; Fri, 03 Jan 2014 10:02:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vz6GP-0005Tq-Hs for emacs-orgmode@gnu.org; Fri, 03 Jan 2014 10:02:23 -0500 Received: from mail-we0-x22a.google.com ([2a00:1450:400c:c03::22a]:55482) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vz6GP-0005Tc-B3 for emacs-orgmode@gnu.org; Fri, 03 Jan 2014 10:02:17 -0500 Received: by mail-we0-f170.google.com with SMTP id w61so13733166wes.1 for ; Fri, 03 Jan 2014 07:02:16 -0800 (PST) In-Reply-To: (Michael Hoffman's message of "Thu, 02 Jan 2014 11:58:32 -0500") 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 Hoffman Cc: emacs-orgmode@gnu.org Hi, Michael Hoffman writes: > On 12/01/2013 12:12 PM, Michael Crouch wrote: >> Bug report for 8.2.3c: >> >> When org-agenda-sorting-strategy is set to deadline-up (or similar >> values), the Global Todo list always places non-timestamped entries at >> the beginning, even when org-sort-agenda-notime-is-late is true. This >> is inconsistent with the behavior when org-agenda-sorting-strategy is >> time-up. >> >> I believe the problem is that the org-cmp-ts function copied a line from >> the older org-cmp-time function: >> (def (if org-sort-agenda-notime-is-late 9901 -1)) >> >> 9901 is later than all times of day, but not later than all date/time >> stamps. > > I get this too on org 8.2.4. Replacing 9901 with most-positive-fixnum > fixes the problem. This is now fixed in maint. Thanks for reporting this and for providing the fix. -- Bastien