From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id 8LRcMEsL4l/mYwAA0tVLHw (envelope-from ) for ; Tue, 22 Dec 2020 15:05:47 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id EGYmLEsL4l/GVAAAB5/wlQ (envelope-from ) for ; Tue, 22 Dec 2020 15:05:47 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 0D3A19404FD for ; Tue, 22 Dec 2020 15:05:47 +0000 (UTC) Received: from localhost ([::1]:41388 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1krjEP-0000mx-Tw for larch@yhetil.org; Tue, 22 Dec 2020 10:05:45 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:58212) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1krjE3-0000lh-MH for emacs-orgmode@gnu.org; Tue, 22 Dec 2020 10:05:23 -0500 Received: from coral.adamspiers.org ([2001:ba8:1f1:f27f::2]:54006) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1krjE0-0003Q0-FK for emacs-orgmode@gnu.org; Tue, 22 Dec 2020 10:05:23 -0500 Received: from localhost (243.103.2.81.in-addr.arpa [81.2.103.243]) by coral.adamspiers.org (Postfix) with ESMTPSA id A5FC82ED48 for ; Tue, 22 Dec 2020 15:05:16 +0000 (GMT) Date: Tue, 22 Dec 2020 15:05:16 +0000 From: Adam Spiers To: org-mode mailing list Subject: Re: overloading of internal priority calculations in agenda Message-ID: <20201222150516.kqounuguau3odhr7@gmail.com> X-OS: GNU/Linux References: <20201202142053.zexzdpmyv4ear3zc@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20201202142053.zexzdpmyv4ear3zc@gmail.com> Received-SPF: pass client-ip=2001:ba8:1f1:f27f::2; envelope-from=orgmode@adamspiers.org; helo=coral.adamspiers.org X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -2.22 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=adamspiers.org (policy=none); spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Queue-Id: 0D3A19404FD X-Spam-Score: -2.22 X-Migadu-Scanner: scn1.migadu.com X-TUID: GYQr6yeOyeyZ Hi again, On Wed, Dec 02, 2020 at 02:20:53PM +0000, Adam Spiers wrote: >Hi all, > >I'm currently working on adding a feature to org-agenda which allows >manual ordering of entries in combination with the existing automatic >ordering (as dictated by `org-agenda-sorting-strategy'). > >During my investigations I noticed that while `org-get-priority' converts >[#B] style cookies into a numeric priority which is a multiple of >1000, further adjustments are made in functions like >`org-agenda-get-scheduled' before adding this numeric priority as a >text property on the entry: > > 'priority (if habitp (org-habit-get-priority habitp) > (+ 99 diff (org-get-priority item))) > >In this case `diff' refers to the number of days between now and when >the item was scheduled. A slightly different calculation is made in >`org-agenda-get-timestamps': > > (org-add-props item props > 'priority (if habit? > (org-habit-get-priority (org-habit-parse-todo)) > (org-get-priority item)) > >I further noticed that this overloading of the internal priority by >including timestamp and habit data causes disruption to the behaviour >I imagine most users would expect from `org-agenda-sorting-strategy'. >For example, if you have `priority-down' as the first entry in the >`agenda' section and `category-keep' as the second, then differences >in the SCHEDULED timestamp are included in the priority calculation >and can therefore prevent sorting of two adjacent [#B] items by >category. This seems like a bug to me, or at least breaks the >Principle of Least Surprise. [snipped] >Given that `org-agenda-sorting-strategy' now supports all manner of >sorting criteria, many of which are time-sensitive, I would like to >know if there is any reason not to remove this overloading of the >priority calculation, i.e. decoupling it to depend purely on the >result of `org-get-priority' and `org-habit-get-priority'? > >If fact, perhaps we could go one step further and add support for new >habit-priority-{up,down} sorters to `org-agenda-sorting-strategy', so >that the priority-{up,down} sorters sort purely by the priority cookie >and nothing else? Gently bumping this as I didn't get any replies yet. I would like to continue working on a solution, but obviously don't want to waste time on something which would be rejected. If it is considered important to preserve the exact behaviour currently offered by `org-agenda-sorting-strategy' then I would propose the following: - Keep the existing priority-{up,down} which combine priority cookies with timestamp data and the result from `org-habit-get-priority', but probably also deprecate it and remove it from the default value. - Introduce new priority-cookie-{up,down} sorters which operate purely on [#A] and [#1] style priority cookies and nothing else. This would facilitate decoupling of the sortable criteria whilst remaining backwards compatible. Does this sound reasonable? I am keen to proceed very soon (ideally over the Xmas break). I have already written some new ert tests for `org-agenda-sorting-strategy' which would be included in any submitted patches. Thanks! Adam