From: Adam Spiers <orgmode@adamspiers.org>
To: Bastien <bzg@gnu.org>
Cc: emacs-orgmode@gnu.org
Subject: Re: [PATCH] [WIP] org-agenda.el: Make org-entries-lessp more efficient
Date: Sat, 24 Oct 2020 17:10:59 +0100 [thread overview]
Message-ID: <20201024161059.zokctln74l5rxvms@ionian.linksys.moosehall> (raw)
In-Reply-To: <877drfonyy.fsf@gnu.org>
On Sat, Oct 24, 2020 at 01:36:05PM +0200, Bastien wrote:
>Hi Adam,
>
>this looks good to me, thanks a lot.
Thanks for the review :-)
>Does "WIP" means that you want to wait for other patches to complete
>this one or shall I apply this one already?
The intention is for it to be a standalone patch, so I don't think
there's any need to wait for other patches. The "WIP" was coming more
from the fact that I haven't done extensive testing to make sure I
didn't break a single one of the many sorting criteria - especially
this one:
+ ('category-keep (if (org-cmp-category a b) +1 nil)) ;; FIXME: check this
Ideally there would already be unit and/or functional tests covering
agenda sorting, but I can't see any and I imagine they would be
non-trivial to add (although perhaps not too difficult either).
Also, the previous behaviour was to silently ignore
user-defined-{up,down} if org-agenda-cmp-user-defined was not defined,
but that intuitively felt wrong to me (IMHO it kind of violates the
Principle of Least Surprise) so I didn't bother to preserve that
behaviour. However I admit that is a pretty subjective choice, so if
you think the existing behaviour should be preserved, I can tweak the
code to do that. In fact, even if you agree with me that it would be
better to generate an error when user-defined-{up,down} is used with
org-agenda-cmp-user-defined being nil, I just noticed that it currently
generates the very unhelpful error:
org-entries-cmp-1: Symbol’s function definition is void: nil
so we would want to explicitly catch that case and generate a more
helpful error message, e.g. "org-agenda-sorting-strategy contains
user-defined sorting but org-agenda-cmp-user-defined is nil".
BTW, as you can partially see from the below link, I did some
performance profiling relating to this change and it did indeed seem
to shave a few milliseconds off org-entries-lessp, although in the
grand scheme of things, that didn't make as much of a dent in
org-agenda's running time as I'd hoped for ;-)
https://gist.github.com/trishume/40bf7045a23412d4c016f5e8533437db#gistcomment-3494087
next prev parent reply other threads:[~2020-10-24 16:11 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-19 1:11 [PATCH] [WIP] org-agenda.el: Make org-entries-lessp more efficient Adam Spiers
2020-10-24 11:36 ` Bastien
2020-10-24 16:10 ` Adam Spiers [this message]
2021-04-27 20:48 ` Bastien
2021-05-15 13:51 ` Bastien
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201024161059.zokctln74l5rxvms@ionian.linksys.moosehall \
--to=orgmode@adamspiers.org \
--cc=bzg@gnu.org \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).