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 CHw/Hlmjx19lPgAA0tVLHw (envelope-from ) for ; Wed, 02 Dec 2020 14:23:21 +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 ENgCGlmjx18iQAAAB5/wlQ (envelope-from ) for ; Wed, 02 Dec 2020 14:23:21 +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 9193294043A for ; Wed, 2 Dec 2020 14:23:20 +0000 (UTC) Received: from localhost ([::1]:51482 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kkT2M-00015L-4B for larch@yhetil.org; Wed, 02 Dec 2020 09:23:18 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:60830) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kkT07-0007Ny-TK for emacs-orgmode@gnu.org; Wed, 02 Dec 2020 09:20:59 -0500 Received: from coral.adamspiers.org ([2001:ba8:1f1:f27f::2]:45266) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kkT05-00031S-D0 for emacs-orgmode@gnu.org; Wed, 02 Dec 2020 09:20:59 -0500 Received: from localhost (243.103.2.81.in-addr.arpa [81.2.103.243]) by coral.adamspiers.org (Postfix) with ESMTPSA id 302B32EDEB for ; Wed, 2 Dec 2020 14:20:54 +0000 (GMT) Date: Wed, 2 Dec 2020 14:20:53 +0000 From: Adam Spiers To: org-mode mailing list Subject: overloading of internal priority calculations in agenda Message-ID: <20201202142053.zexzdpmyv4ear3zc@gmail.com> X-OS: GNU/Linux MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline 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.18 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: 9193294043A X-Spam-Score: -2.18 X-Migadu-Scanner: ns3122888.ip-94-23-21.eu X-TUID: s1HXh+SRs3NF 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. I did some git archaelogy and found that the first ever git commit 4be4c562 (for release 4.12a) already includes `org-agenda-sorting-strategy', but at that point, time-{up,down} were the only time-related sorting criteria available. I was also wondering where the magic 99 number above came from, and I found that the same (first ever) commit introduced the following priority calculation: (+ (- 5 diff) (org-get-priority txt)) Subsequently, commit 70b6cc5d (for release 5.10a) changes this to: (+ 94 (- 5 diff) (org-get-priority txt)) and then commit 69ec6258 (on 2016-11-25) changes it to (+ 99 diff (org-get-priority item)) 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? Thanks! Adam