6b/cccaa5ddbf17cb699d12d21ea45f8385650597

   1 Return-Path: <dme@dme.org>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id 5A62B431FC1\r
   6         for <notmuch@notmuchmail.org>; Mon,  7 Jun 2010 06:50:05 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -1.89\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5\r
  12         tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_MIME_NO_TEXT=0.01]\r
  13         autolearn=unavailable\r
  14 Received: from olra.theworths.org ([127.0.0.1])\r
  15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  16         with ESMTP id 1rim9Vkrftt7 for <notmuch@notmuchmail.org>;\r
  17         Mon,  7 Jun 2010 06:49:50 -0700 (PDT)\r
  18 Received: from mail-ww0-f53.google.com (mail-ww0-f53.google.com\r
  19  [74.125.82.53])        by olra.theworths.org (Postfix) with ESMTP id 59A084196F0       for\r
  20  <notmuch@notmuchmail.org>; Mon,  7 Jun 2010 06:49:50 -0700 (PDT)\r
  21 Received: by wwb39 with SMTP id 39so2002306wwb.26\r
  22         for <notmuch@notmuchmail.org>; Mon, 07 Jun 2010 06:49:48 -0700 (PDT)\r
  23 Received: by 10.227.154.147 with SMTP id o19mr14248615wbw.112.1275918587703;\r
  24         Mon, 07 Jun 2010 06:49:47 -0700 (PDT)\r
  25 Received: from ut.hh.sledj.net (gmp-ea-fw-1b.sun.com [192.18.8.1])\r
  26         by mx.google.com with ESMTPS id u36sm37999870wbv.0.2010.06.07.06.49.24\r
  27         (version=TLSv1/SSLv3 cipher=RC4-MD5);\r
  28         Mon, 07 Jun 2010 06:49:45 -0700 (PDT)\r
  29 Received: by ut.hh.sledj.net (Postfix, from userid 1000)\r
  30         id E97C6594015; Mon,  7 Jun 2010 14:49:26 +0100 (BST)\r
  31 To: Carl Worth <cworth@cworth.org>, Keith Packard <keithp@keithp.com>,\r
  32         notmuch@notmuchmail.org\r
  33 Subject: Re: [PATCH] Customize saved search order separately from regular\r
  34         search order\r
  35 In-Reply-To: <87d3w7eicf.fsf@yoom.home.cworth.org>\r
  36 References: <1272920307-25995-1-git-send-email-keithp@keithp.com>\r
  37         <87d3xcexq9.fsf@ut.hh.sledj.net>\r
  38         <87d3w7eicf.fsf@yoom.home.cworth.org>\r
  39 User-Agent: Notmuch/0.3.1-50-gc535d0a (http://notmuchmail.org) Emacs/23.1.1\r
  40         (x86_64-pc-linux-gnu)\r
  41 From: David Edmondson <dme@dme.org>\r
  42 Date: Mon, 07 Jun 2010 14:49:23 +0100\r
  43 Message-ID: <87ocfnt0kc.fsf@ut.hh.sledj.net>\r
  44 MIME-Version: 1.0\r
  45 Content-Type: multipart/signed; boundary="=-=-=";\r
  46         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  47 X-BeenThere: notmuch@notmuchmail.org\r
  48 X-Mailman-Version: 2.1.13\r
  49 Precedence: list\r
  50 List-Id: "Use and development of the notmuch mail system."\r
  51         <notmuch.notmuchmail.org>\r
  52 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  53         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  54 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  55 List-Post: <mailto:notmuch@notmuchmail.org>\r
  56 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  57 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  58         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  59 X-List-Received-Date: Mon, 07 Jun 2010 13:50:05 -0000\r
  60 \r
  61 --=-=-=\r
  62 Content-Transfer-Encoding: quoted-printable\r
  63 \r
  64 On Thu, 03 Jun 2010 17:45:20 -0700, Carl Worth <cworth@cworth.org> wrote:\r
  65 > So I think what we actually want here is an additional member for our\r
  66 > saved-search tuple which indicates the desired search order for that\r
  67 > particular search. That's the only way I see to support a single user\r
  68 > who wants to take advantage of both kinds of searches.\r
  69 \r
  70 That seems straightforward to implement in the code and only slightly\r
  71 complicated in the customisation interface (though I haven't done it\r
  72 yet).\r
  73 \r
  74 > A separated, but perhaps related idea would be to explicitly support the\r
  75 > notion of one search being a subset of another. I have an "inbox" search\r
  76 > (tag:inbox) and several searches that are subsets, ("notmuch" is\r
  77 > "tag:notmuch and tag:inbox"). If this were setup as an actual hierarchy\r
  78 > it might have two advantages:\r
  79 >=20\r
  80 >       1. It would be a bit simpler to specify all of theses searches,\r
  81 >          I wouldn't have to keep repeating "and tag:inbox" in each.\r
  82 >          This would be particularly important if I changed the\r
  83 >          criteria for the top-level search.\r
  84 >=20\r
  85 >       2. If the various levels of the hierarchy were displayed\r
  86 >          separately it would be easier for me to focus on processing\r
  87 >          all of my inbox folders (which happen to be\r
  88 >          oldest-first)--archiving each down to 0 messages, without\r
  89 >          being distracted by several (newest-first) saved searches\r
  90 >          that will only ever grow and don't have any\r
  91 >          processing/archiving associated with them.\r
  92 \r
  93 Writing code to manipulate and use a structure like this would obviously\r
  94 be some effort, but it doesn't seem overly difficult. More challenging\r
  95 would be the interface to allow the user to customise the structure to\r
  96 express their intentions. Do you have any thoughts on that?\r
  97 \r
  98 dme.\r
  99 =2D-=20\r
 100 David Edmondson, http://dme.org\r
 101 \r
 102 --=-=-=\r
 103 Content-Type: application/pgp-signature\r
 104 \r
 105 -----BEGIN PGP SIGNATURE-----\r
 106 Version: GnuPG v1.4.10 (GNU/Linux)\r
 107 \r
 108 iEYEARECAAYFAkwM+OMACgkQaezQq/BJZRZgIACdHnrFFyvcrK1oVRpHqlNiU6sP\r
 109 0DMAniy9r59CjNaMf4nP9IkES3ehLMdY\r
 110 =xHhJ\r
 111 -----END PGP SIGNATURE-----\r
 112 --=-=-=--\r