d3/fc139ae1babc4dd4a17ead26465bb5e78060b0

   1 Return-Path: <jan@ryngle.com>\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 D4A3A431FBF\r
   6         for <notmuch@notmuchmail.org>; Thu, 19 Nov 2009 07:40:34 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 Received: from olra.theworths.org ([127.0.0.1])\r
   9         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  10         with ESMTP id kHnsMSVR0zol for <notmuch@notmuchmail.org>;\r
  11         Thu, 19 Nov 2009 07:40:34 -0800 (PST)\r
  12 Received: from mail-fx0-f217.google.com (mail-fx0-f217.google.com\r
  13         [209.85.220.217])\r
  14         by olra.theworths.org (Postfix) with ESMTP id 14706431FAE\r
  15         for <notmuch@notmuchmail.org>; Thu, 19 Nov 2009 07:40:33 -0800 (PST)\r
  16 Received: by fxm9 with SMTP id 9so2551475fxm.30\r
  17         for <notmuch@notmuchmail.org>; Thu, 19 Nov 2009 07:40:33 -0800 (PST)\r
  18 MIME-Version: 1.0\r
  19 Received: by 10.204.155.92 with SMTP id r28mr131734bkw.121.1258645232952; Thu,\r
  20         19 Nov 2009 07:40:32 -0800 (PST)\r
  21 In-Reply-To: <87lji2bmrb.fsf@yoom.home.cworth.org>\r
  22 References: <1258630481-5133-1-git-send-email-jan@ryngle.com>\r
  23         <1258630481-5133-2-git-send-email-jan@ryngle.com>\r
  24         <f35dbb950911190352q2dcd041fr83a2f722f3231f44@mail.gmail.com>\r
  25         <87lji2bmrb.fsf@yoom.home.cworth.org>\r
  26 Date: Thu, 19 Nov 2009 16:40:32 +0100\r
  27 Message-ID: <f35dbb950911190740w7d19c0e3s7a731322ae42b7b2@mail.gmail.com>\r
  28 From: Jan Janak <jan@ryngle.com>\r
  29 To: Carl Worth <cworth@cworth.org>\r
  30 Content-Type: text/plain; charset=UTF-8\r
  31 Cc: notmuch@notmuchmail.org\r
  32 Subject: Re: [notmuch] [PATCH 2/2] notmuch list: A new command to produce\r
  33         various lists.\r
  34 X-BeenThere: notmuch@notmuchmail.org\r
  35 X-Mailman-Version: 2.1.12\r
  36 Precedence: list\r
  37 List-Id: "Use and development of the notmuch mail system."\r
  38         <notmuch.notmuchmail.org>\r
  39 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  40         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  41 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  42 List-Post: <mailto:notmuch@notmuchmail.org>\r
  43 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  44 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  45         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  46 X-List-Received-Date: Thu, 19 Nov 2009 15:40:35 -0000\r
  47 \r
  48 On Thu, Nov 19, 2009 at 3:41 PM, Carl Worth <cworth@cworth.org> wrote:\r
  49 > On Thu, 19 Nov 2009 12:52:49 +0100, Jan Janak <jan@ryngle.com> wrote:\r
  50 >> I implemented a new notmuch command that can be used to list all tags\r
  51 >> present in the database:\r
  52 >\r
  53 > Ah, very very interesting! I'd been planning on doing something like\r
  54 > this soon. And I was just thinking of "notmuch tags" as the command\r
  55 > line. What other ideas do you have in mind for "notmuch list" ?\r
  56 \r
  57 Yes, I considered "notmuch tags" too, but then I realized that we\r
  58 already have "notmuch tag" and I was worried that having both tag and\r
  59 tags as commands could be confusing.\r
  60 \r
  61 I was also thinking that "notmuch list" could be extended to list\r
  62 other terms than just tags, but I currently have no use-case for that.\r
  63 \r
  64 In any case, this is just an initial proposal, I can change it to use\r
  65 some other command name if you prefer that.\r
  66 \r
  67 > One way we could possibly do "notmuch tags" is to have it accept search\r
  68 > terms and then return the list of all tags from the matched messages.\r
  69 > Then of course we'd need a syntax for a search term to match all\r
  70 > messages, (which we want in any case).\r
  71 \r
  72 That sounds like a good idea. If the user does not provide any search\r
  73 terms then we could return all tags from the database like we do now.\r
  74 If there is a search term then we could iterate through all the\r
  75 messages that match it, collect their tags, sort them and present to\r
  76 the user.\r
  77 \r
  78 >> The main reason why I implemented this is because I am also working on\r
  79 >> adding the tag completion feature to the Emacs mode. This is very\r
  80 >> useful if you have a large collection of tags--it can save you some\r
  81 >> typing and, perhaps more importantly, it minimizes the risk of having\r
  82 >> typos in tag names. I'll send a patch for that later too.\r
  83 >\r
  84 > That will be a very nice feature to have, yes.\r
  85 >\r
  86 > The other reason I've wanted this is have something like a "folder view"\r
  87 > that would show a list of tags and a number of messages with each tag,\r
  88 > (or a number of messages with that tag and the inbox tag).\r
  89 \r
  90 Yeah, I would want that too :-). I've already looked into this and it\r
  91 seems like it should be easy to implement. At least it seems to be\r
  92 easy to get the numbers from Xapian. So we would just need to come up\r
  93 with a format for the list of tags with message counts, read it into\r
  94 emacs and present in a buffer.\r
  95 \r
  96   -- Jan\r