From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id 399AB6DE0196 for ; Sat, 20 Oct 2018 04:51:56 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[AWL=0.005, SPF_PASS=-0.001] autolearn=disabled Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyGftp_gcVF2 for ; Sat, 20 Oct 2018 04:51:55 -0700 (PDT) Received: from fethera.tethera.net (fethera.tethera.net [198.245.60.197]) by arlo.cworth.org (Postfix) with ESMTPS id 605EA6DE0141 for ; Sat, 20 Oct 2018 04:51:55 -0700 (PDT) Received: from remotemail by fethera.tethera.net with local (Exim 4.89) (envelope-from ) id 1gDpnO-0007E4-9C; Sat, 20 Oct 2018 07:51:54 -0400 Received: (nullmailer pid 29696 invoked by uid 1000); Sat, 20 Oct 2018 11:51:53 -0000 From: David Bremner To: William Casarin , notmuch@notmuchmail.org Subject: Re: [PATCH 1/2] WIP: groundwork for new sorting API In-Reply-To: <87k1msp3g7.fsf@jb55.com> References: <20171210154956.4049-1-david@tethera.net> <20171210154956.4049-2-david@tethera.net> <87k1msp3g7.fsf@jb55.com> Date: Sat, 20 Oct 2018 08:51:53 -0300 Message-ID: <87h8hgu97q.fsf@tethera.net> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2018 11:51:56 -0000 William Casarin writes: > > > I'm adding a few new keys (from, subject, etc). I don't want to > duplicate them in the old notmuch_sort_t enum, I assume to move to the > new API there should be something like this as well? It's been a while since I was thinking about this, but I suspect my intent was that new keys could be supported (only) by the new API. We basically want to deprecate the old API as soon as the new one exists to transition to. > > > Then we could eventually do something like: > > --sort date:desc,from:asc > > Which would mean: sort by date, and then by from. I think the "notmuch way" would be to spell out descending and ascending, and rely on completion to make that less painful to type. I only mention it because I was confused by what "desc" and "asc" stood for. For some reason descriptor and ascii jumped to my pre-caffeinated mind. > Perhaps it could do something sensible by default without order > qualifiers as well: > > --sort date,from I would hope so, yes.