21/04caf14cb0e16fd2d218974a2927eeec620634

   1 Return-Path: <wavexx@thregr.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 arlo.cworth.org (Postfix) with ESMTP id 0FC1B6DE02B5\r
   6  for <notmuch@notmuchmail.org>; Thu,  4 Aug 2016 10:21:50 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at cworth.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -1.159\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-1.159 tagged_above=-999 required=5\r
  12  tests=[AWL=-1.148, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01]\r
  13  autolearn=disabled\r
  14 Received: from arlo.cworth.org ([127.0.0.1])\r
  15  by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
  16  with ESMTP id GLO-wcDcUDSd for <notmuch@notmuchmail.org>;\r
  17  Thu,  4 Aug 2016 10:21:42 -0700 (PDT)\r
  18 Received: from e.thregr.org (e.thregr.org [80.68.88.20])\r
  19  by arlo.cworth.org (Postfix) with ESMTPS id B9A566DE02B0\r
  20  for <notmuch@notmuchmail.org>; Thu,  4 Aug 2016 10:21:41 -0700 (PDT)\r
  21 Received: from [2a02:27e8:20:9049:56ee:75ff:fe83:444c] (helo=localhost)\r
  22  by e.thregr.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\r
  23  (Exim 4.87) (envelope-from <wavexx@thregr.org>)\r
  24  id 1bVMKy-0003oe-1U; Thu, 04 Aug 2016 19:21:40 +0200\r
  25 From: Yuri D'Elia <wavexx@thregr.org>\r
  26 To: Jani Nikula <jani@nikula.org>, notmuch@notmuchmail.org\r
  27 Subject: Re: Flat search and threaded views\r
  28 In-Reply-To: <877fbwv6h5.fsf@nikula.org>\r
  29 References: <87k2fwbl24.fsf@wavexx.thregr.org> <877fbwv6h5.fsf@nikula.org>\r
  30 User-Agent: Notmuch/ (https://notmuchmail.org) Emacs/24.5.1\r
  31  (x86_64-pc-linux-gnu)\r
  32 Date: Thu, 04 Aug 2016 19:21:39 +0200\r
  33 Message-ID: <87eg64bgbg.fsf@wavexx.thregr.org>\r
  34 MIME-Version: 1.0\r
  35 Content-Type: text/plain\r
  36 X-BeenThere: notmuch@notmuchmail.org\r
  37 X-Mailman-Version: 2.1.20\r
  38 Precedence: list\r
  39 List-Id: "Use and development of the notmuch mail system."\r
  40  <notmuch.notmuchmail.org>\r
  41 List-Unsubscribe: <https://notmuchmail.org/mailman/options/notmuch>,\r
  42  <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  43 List-Archive: <http://notmuchmail.org/pipermail/notmuch/>\r
  44 List-Post: <mailto:notmuch@notmuchmail.org>\r
  45 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  46 List-Subscribe: <https://notmuchmail.org/mailman/listinfo/notmuch>,\r
  47  <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  48 X-List-Received-Date: Thu, 04 Aug 2016 17:21:50 -0000\r
  49 \r
  50 On Thu, Aug 04 2016, Jani Nikula <jani@nikula.org> wrote:\r
  51 >> I'd like to jump directly to the first unread message (and in detail, to\r
  52 >> the first message that actually matches the query!). It's really not\r
  53 >> great to have to find what message matched the query, especially for\r
  54 >> long-running threads.\r
  55 >\r
  56 > For me, hitting RET in search does show the first matching message in\r
  57 > the thread.\r
  58 \r
  59 Ok, I see now.\r
  60 \r
  61 The problem is that the search I've built includes both existing\r
  62 messages and unread ones (with a buffer of a day). So even though I get\r
  63 a new (unread) message, some existing messages in the thread also match.\r
  64 When reading a new thread started within the day, all messages match.\r
  65 \r
  66 So I have a different question:\r
  67 \r
  68 Can I customize how to jump within a thread? I understand 'unread' is\r
  69 nothing special and I'd like to keep it that way. So I'd like a quick\r
  70 way to navigate within a thread to skip to messages matching a certain\r
  71 tag (ie: unread).\r
  72 \r
  73 With that, I could setup a hook in notmuch-show to improve the behavior\r
  74 without making unread special.\r
  75 \r
  76 > The idea is that the unread tag gets dropped when the cursor visits the\r
  77 > region of an expanded message, in an approximation of when the user has\r
  78 > actually read the message. We spent quite a bit of time on this, and at\r
  79 > least I like this behaviour very much, especially with the red\r
  80 > overstrike on the unread tag in the buffer.\r
  81 \r
  82 I've seen this, but it wasn't clear how it was working. I see now the\r
  83 mechanism, but I need a convenient way to jump to tags in a show buffer.\r
  84 \r
  85 I have to say, as Matt experienced, I wasn't sure how messages where\r
  86 expanded until I read that message.\r
  87 \r
  88 > I suppose we could use a feature to tag matching messages from the\r
  89 > search view and expanded messages from the show view. You can of course\r
  90 > do this on the command-line.\r
  91 \r
  92 You mean 'notmuch tag'? Isn't this what '*' would do?\r
  93 \r
  94 >> Is there a way to sort the search (either tree/search) by subject or\r
  95 >> by author? Rarely useful, but it doesn't seem possible.\r
  96 >\r
  97 > I don't think so.\r
  98 \r
  99 I also didn't see a way to do that from the command line.\r