ad/eba6e6ee8dab3ba5da09ac7977179372acf0b6

   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 354FD4196F0\r
   6         for <notmuch@notmuchmail.org>; Wed,  9 Jun 2010 08:36:42 -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=ham\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 BBJ9a9bDZp72 for <notmuch@notmuchmail.org>;\r
  17         Wed,  9 Jun 2010 08:36:31 -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 85C13431FC1       for\r
  20  <notmuch@notmuchmail.org>; Wed,  9 Jun 2010 08:36:31 -0700 (PDT)\r
  21 Received: by wwb39 with SMTP id 39so3991284wwb.26\r
  22         for <notmuch@notmuchmail.org>; Wed, 09 Jun 2010 08:36:30 -0700 (PDT)\r
  23 Received: by 10.227.69.204 with SMTP id a12mr2196841wbj.153.1276097789726;\r
  24         Wed, 09 Jun 2010 08:36:29 -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 u36sm56745968wbv.0.2010.06.09.08.36.25\r
  27         (version=TLSv1/SSLv3 cipher=RC4-MD5);\r
  28         Wed, 09 Jun 2010 08:36:26 -0700 (PDT)\r
  29 Received: by ut.hh.sledj.net (Postfix, from userid 1000)\r
  30         id 49708594015; Wed,  9 Jun 2010 16:36:57 +0100 (BST)\r
  31 To: Jameson Rollins <jrollins@finestructure.net>,\r
  32         Notmuch Mail <notmuch@notmuchmail.org>\r
  33 Subject: Re: [PATCH] remove message archiving from show-advance-and-archive\r
  34 In-Reply-To: <87sk4wxm7j.fsf@servo.finestructure.net>\r
  35 References: <87zkz4xnf4.fsf@servo.finestructure.net>\r
  36         <874ohctf2h.fsf@ut.hh.sledj.net>\r
  37         <87sk4wxm7j.fsf@servo.finestructure.net>\r
  38 User-Agent: Notmuch/0.3.1-50-gc535d0a (http://notmuchmail.org) Emacs/23.1.1\r
  39         (x86_64-pc-linux-gnu)\r
  40 From: David Edmondson <dme@dme.org>\r
  41 Date: Wed, 09 Jun 2010 16:36:53 +0100\r
  42 Message-ID: <87wru8rze2.fsf@ut.hh.sledj.net>\r
  43 MIME-Version: 1.0\r
  44 Content-Type: multipart/signed; boundary="=-=-=";\r
  45         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  46 X-BeenThere: notmuch@notmuchmail.org\r
  47 X-Mailman-Version: 2.1.13\r
  48 Precedence: list\r
  49 List-Id: "Use and development of the notmuch mail system."\r
  50         <notmuch.notmuchmail.org>\r
  51 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  52         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  53 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  54 List-Post: <mailto:notmuch@notmuchmail.org>\r
  55 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  56 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  57         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  58 X-List-Received-Date: Wed, 09 Jun 2010 15:36:42 -0000\r
  59 \r
  60 --=-=-=\r
  61 Content-Transfer-Encoding: quoted-printable\r
  62 \r
  63 On Wed, 09 Jun 2010 11:25:04 -0400, Jameson Rollins <jrollins@finestructure=\r
  64 .net> wrote:\r
  65 > On Wed, 09 Jun 2010 16:12:54 +0100, David Edmondson <dme@dme.org> wrote:\r
  66 > > On Wed, 9 Jun 2010 10:49:43 -0400, Jameson Rollins <jrollins@finestruct=\r
  67 ure.net> wrote:\r
  68 > > > The function to advance through threads with the space bar is useful.\r
  69 > > > However, the current implementation also archives messages.  The idea\r
  70 > > > of archiving a message should not be intertwined with the processes of\r
  71 > > > advancing through messages to read them.  Archiving in general should\r
  72 > > > be a separate operation that one does explicitly.  This patch just\r
  73 > > > renames the advance function "notmuch-show-advance", and removes the\r
  74 > > > archiving of a thread when the end of the thread is reached.\r
  75 > >=20\r
  76 > > This is great, but what if I want the current behaviour?\r
  77 >=20\r
  78 > Well, you could do like I do now, and write a function that does what\r
  79 > you want and bind it to whatever key you want.  But I really don't think\r
  80 > the current behavior should be the default.\r
  81 \r
  82 I'm not overly worried about the default behaviour, just with what\r
  83 behaviour is easily available.\r
  84 \r
  85 > The current behavior completely mixes the meaning of "unread" and\r
  86 > "inbox".  If there is no difference between the meaning of those tags,\r
  87 > then why have separate tags for them?\r
  88 \r
  89 They are clearly different. If I read a thread with 'space' the 'unread'\r
  90 tag is removed from the messages as I pass them by. I can then 'q' from\r
  91 the thread and the messages are not archived ('inbox' is not removed),\r
  92 but they are no longer 'unread'.\r
  93 \r
  94 > I think we've done some good work in making the "unread" tag correspond\r
  95 > reasonably well to actually viewing a message.  We have lots of good\r
  96 > automatic removal of that tag when messages are viewed.  But I really\r
  97 > feel strongly that "unread" is the *only* tag that we should be handling\r
  98 > in an automated way like that.  We should really leave it to the user to\r
  99 > handle all other tags explicitly how they see fit.  I certainly don't\r
 100 > want every message I read automatically removed from my inbox.\r
 101 >=20\r
 102 > If you feel really strongly about this in the other direction, I would\r
 103 > like to understand why.  If we can't resolve, then maybe a vote?\r
 104 \r
 105 Maybe you could submit a patch which allows a user to choose the\r
 106 behaviour with a customisation variable? (Though I'd expect the value of\r
 107 that variable to preserve backward compatible behaviour until Carl says\r
 108 otherwise.)\r
 109 \r
 110 dme.\r
 111 =2D-=20\r
 112 David Edmondson, http://dme.org\r
 113 \r
 114 --=-=-=\r
 115 Content-Type: application/pgp-signature\r
 116 \r
 117 -----BEGIN PGP SIGNATURE-----\r
 118 Version: GnuPG v1.4.10 (GNU/Linux)\r
 119 \r
 120 iEYEARECAAYFAkwPtRYACgkQaezQq/BJZRZkMQCfU/OvnptzjRdkNXuPBcy2QpRx\r
 121 Tf0AmwUjqJgJxVARCHG8HzQy5blKOykg\r
 122 =tOlp\r
 123 -----END PGP SIGNATURE-----\r
 124 --=-=-=--\r