f4/15abbc4dbc0e3ad7a86a3d4ef3b28a34251838

   1 Return-Path:\r
   2  <return-5dt29heut3f7yu8ivip6q9jag6@temporary-address.scs.stanford.edu>\r
   3 X-Original-To: notmuch@notmuchmail.org\r
   4 Delivered-To: notmuch@notmuchmail.org\r
   5 Received: from localhost (localhost [127.0.0.1])\r
   6  by arlo.cworth.org (Postfix) with ESMTP id 385886DE02C2\r
   7  for <notmuch@notmuchmail.org>; Mon,  4 Apr 2016 22:29:02 -0700 (PDT)\r
   8 X-Virus-Scanned: Debian amavisd-new at cworth.org\r
   9 X-Spam-Flag: NO\r
  10 X-Spam-Score: -2.065\r
  11 X-Spam-Level: \r
  12 X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=0.246,\r
  13   RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01]\r
  14  autolearn=disabled\r
  15 Received: from arlo.cworth.org ([127.0.0.1])\r
  16  by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
  17  with ESMTP id ILH1B2pmg0Yv for <notmuch@notmuchmail.org>;\r
  18  Mon,  4 Apr 2016 22:28:54 -0700 (PDT)\r
  19 Received: from market.scs.stanford.edu (market.scs.stanford.edu [171.66.3.10])\r
  20  by arlo.cworth.org (Postfix) with ESMTPS id 1EE246DE0243\r
  21  for <notmuch@notmuchmail.org>; Mon,  4 Apr 2016 22:28:54 -0700 (PDT)\r
  22 Received: from market.scs.stanford.edu (localhost.scs.stanford.edu\r
  23  [127.0.0.1]) by market.scs.stanford.edu (8.14.7/8.14.7) with ESMTP id\r
  24  u355Sjmg019344; Mon, 4 Apr 2016 22:28:45 -0700 (PDT)\r
  25 Received: (from dm@localhost)\r
  26  by market.scs.stanford.edu (8.14.7/8.14.7/Submit) id u355SimH017591;\r
  27  Mon, 4 Apr 2016 22:28:44 -0700 (PDT)\r
  28 X-Authentication-Warning: market.scs.stanford.edu: dm set sender to\r
  29  return-5dt29heut3f7yu8ivip6q9jag6@ta.scs.stanford.edu using -f\r
  30 From: David Mazieres <dm-list-email-notmuch@scs.stanford.edu>\r
  31 To: Mark Walters <markwalters1009@gmail.com>, Eric <eric@deptj.eu>,\r
  32  notmuch@notmuchmail.org\r
  33 Subject: Re: Breaking a really long thread\r
  34 In-Reply-To: <87k2kd8r6d.fsf@qmul.ac.uk>\r
  35 References: <c10e501c2baee471cbeeb42aad89a1e966407234-NM@bruno.deptj.eu>\r
  36  <87k2kd8r6d.fsf@qmul.ac.uk>\r
  37 Reply-To: David Mazieres expires 2016-07-03 PDT\r
  38  <mazieres-297ctmng4fhr6h6ad8yffa64yi@temporary-address.scs.stanford.edu>\r
  39 Date: Mon, 04 Apr 2016 22:28:43 -0700\r
  40 Message-ID: <87wpoc7hf8.fsf@ta.scs.stanford.edu>\r
  41 MIME-Version: 1.0\r
  42 Content-Type: text/plain\r
  43 X-BeenThere: notmuch@notmuchmail.org\r
  44 X-Mailman-Version: 2.1.20\r
  45 Precedence: list\r
  46 List-Id: "Use and development of the notmuch mail system."\r
  47  <notmuch.notmuchmail.org>\r
  48 List-Unsubscribe: <https://notmuchmail.org/mailman/options/notmuch>,\r
  49  <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  50 List-Archive: <http://notmuchmail.org/pipermail/notmuch/>\r
  51 List-Post: <mailto:notmuch@notmuchmail.org>\r
  52 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  53 List-Subscribe: <https://notmuchmail.org/mailman/listinfo/notmuch>,\r
  54  <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  55 X-List-Received-Date: Tue, 05 Apr 2016 05:29:02 -0000\r
  56 \r
  57 Mark Walters <markwalters1009@gmail.com> writes:\r
  58 \r
  59 > By default the reference header is hidden. It is controlled by\r
  60 > message-hidden-headers which you can customize. (Note notmuch adds\r
  61 > user-agent to this list via notmuch-mua-hidden-header.)\r
  62 \r
  63 Thanks for explaining this!  So I posted about one problem, and instead\r
  64 got a solution to a problem I didn't even realize I had.  Adding:\r
  65 \r
  66   (setq message-hidden-headers (delete "^References:" message-hidden-headers))\r
  67 \r
  68 to my eval-after-loaded notmuch-config.el file solved this problem\r
  69 cold.  No more unintentional References: headers for me.\r
  70 \r
  71 Arguably, I would say either both the In-Reply-To and the References\r
  72 header should be hidden or neither.  Otherwise, what was happening is\r
  73 that I was deleting the In-Reply-To header as it was the only one I saw,\r
  74 and figuring that maybe References was adjusted after the fact based on\r
  75 In-Reply-To.  After all, the message buffer doesn't keep track of the\r
  76 parent message.\r
  77 \r
  78 Unless there's a reason that someone would want to alter In-Reply-To\r
  79 without altering References, it doesn't make sense to show one without\r
  80 the other.\r
  81 \r
  82 David\r