f6/e4e7956e21e9e75239b8fe190e07f79109e2ea

   1 Return-Path: <lhotka@cesnet.cz>\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 A281640BFAD\r
   6         for <notmuch@notmuchmail.org>; Tue, 24 Aug 2010 05:10:13 -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.9\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5\r
  12         tests=[BAYES_00=-1.9] autolearn=ham\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id LlZbKOTNpj5I for <notmuch@notmuchmail.org>;\r
  16         Tue, 24 Aug 2010 05:10:02 -0700 (PDT)\r
  17 Received: from trail.lhotka.cesnet.cz (trail.lhotka.cesnet.cz\r
  18         [195.113.161.162])\r
  19         by olra.theworths.org (Postfix) with ESMTP id 76F5B40BFAB\r
  20         for <notmuch@notmuchmail.org>; Tue, 24 Aug 2010 05:10:02 -0700 (PDT)\r
  21 Received: from localhost (missotis.lhotkovi.cz [172.29.2.201])\r
  22         (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))\r
  23         (No client certificate requested)\r
  24         by trail.lhotka.cesnet.cz (Postfix) with ESMTPSA id 127403E0656;\r
  25         Tue, 24 Aug 2010 14:10:00 +0200 (CEST)\r
  26 From: Ladislav Lhotka <lhotka@cesnet.cz>\r
  27 To: Michal Sojka <sojkam1@fel.cvut.cz>, notmuch@notmuchmail.org\r
  28 Subject: Re: problem with I-D announcements\r
  29 In-Reply-To: <87iq3a3bak.fsf@steelpick.2x.cz>\r
  30 References: <87pqxisy8p.fsf@cesnet.cz> <87iq3a3bak.fsf@steelpick.2x.cz>\r
  31 User-Agent: Notmuch/0.3.1-59-g676d251 (http://notmuchmail.org) Emacs/23.1.1\r
  32         (i486-pc-linux-gnu)\r
  33 Date: Tue, 24 Aug 2010 14:09:59 +0200\r
  34 Message-ID: <87r5ho6wko.fsf@cesnet.cz>\r
  35 MIME-Version: 1.0\r
  36 Content-Type: text/plain; charset=us-ascii\r
  37 X-BeenThere: notmuch@notmuchmail.org\r
  38 X-Mailman-Version: 2.1.13\r
  39 Precedence: list\r
  40 List-Id: "Use and development of the notmuch mail system."\r
  41         <notmuch.notmuchmail.org>\r
  42 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  43         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  44 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  45 List-Post: <mailto:notmuch@notmuchmail.org>\r
  46 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  47 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  48         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  49 X-List-Received-Date: Tue, 24 Aug 2010 12:10:13 -0000\r
  50 \r
  51 On Mon, 16 Aug 2010 16:02:59 +0200, Michal Sojka <sojkam1@fel.cvut.cz> wrote:\r
  52 > On Mon, 16 Aug 2010, Ladislav Lhotka wrote:\r
  53 > > I am experiencing a problem with a specific type of messages, namely\r
  54 > > announcements of new Internet drafts. One such message is shown below\r
  55 > > with all headers.\r
  56 > > \r
  57 > > In a search buffer, if I press [RET], the message is shown but the echo\r
  58 > > line says "Couldn't find access type". The [SPC] key then doesn't work,\r
  59 > > only "Beginning of buffer" is displayed in the echo area. Other\r
  60 > > commands, such as adding tags, work as usual.\r
  61 > \r
  62 > Greetings to another czech notmuch user :-)\r
  63 > \r
  64 > I can confirm the behavior you describe. It seems the error message is\r
  65 > generated by mm-extern-cache-contents in gnus/mm-extern.el. According to\r
  66 > comments in that file, it works with something called\r
  67 > "message/external-body". Currently, I have no clue what external-body\r
  68 > means but your message contains such thing.\r
  69 > \r
  70 > My poor Elisp knowledge doesn't allow me to debug the problem, but you\r
  71 > may want to check whether the same problem appears in Gnus and if so,\r
  72 > consult it with Gnus developers.\r
  73 \r
  74 With my faint Elisp expertise, I tried to investigate the problem a bit\r
  75 and it seems it is in the notmuch elisp part. The\r
  76 'mm-extern-cache-contents' function you mentioned\r
  77 initializes the 'access-type' variable like this:\r
  78 \r
  79   (let* ((access-type (cdr (assq 'access-type\r
  80                                  (cdr (mm-handle-type handle)))))\r
  81 \r
  82 The 'handle' argument for the problematic message looks like this:\r
  83 (#<buffer  *temp*> ("message/external-body") nil nil nil nil nil nil)\r
  84 \r
  85 Now, 'mm-handle-type' function extracts the second member from 'handle',\r
  86 which is ("message/external-body"). Applying 'cdr' to this list yields\r
  87 necessarily nil and so access-type is always initialized to nil and\r
  88 consequently the error "Couldn't find access type" is reported.\r
  89 \r
  90 The ("message/external-body") list is constructed originally in\r
  91 'notmuch-show-insert-bodypart' function and passed - as 'content-type'\r
  92 argument - through several stack frames. The use of 'cdr' and 'assq'\r
  93 functions in the above initialization expression however indicates that\r
  94 'mm-extern-cache-contents' expects something more complex than just a\r
  95 simple list.\r
  96 \r
  97 Perhaps someone with deeper knowledge of notmuch elisp internals could\r
  98 fix this bug?\r
  99 \r
 100 Cheers, Lada\r
 101  \r
 102 > \r
 103 > Cheers,\r
 104 > Michal\r
 105 \r
 106 -- \r
 107 Ladislav Lhotka, CESNET\r
 108 PGP Key ID: E74E8C0C\r