* problem with I-D announcements
@ 2010-08-16 9:28 Ladislav Lhotka
2010-08-16 14:02 ` Michal Sojka
0 siblings, 1 reply; 4+ messages in thread
From: Ladislav Lhotka @ 2010-08-16 9:28 UTC (permalink / raw)
To: notmuch
Hi,
I am experiencing a problem with a specific type of messages, namely
announcements of new Internet drafts. One such message is shown below
with all headers.
In a search buffer, if I press [RET], the message is shown but the echo
line says "Couldn't find access type". The [SPC] key then doesn't work,
only "Beginning of buffer" is displayed in the echo area. Other
commands, such as adding tags, work as usual.
Is anything wrong with this message?
Thanks, Lada
=====================================================================
From netconf-bounces@ietf.org Fri Aug 13 05:31:04 2010
Return-Path: <netconf-bounces@ietf.org>
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on office2.cesnet.cz
X-Spam-Level:
X-Spam-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,
RCVD_IN_DNSWL_MED autolearn=ham version=3.2.5
X-Original-To: lhotka@office2.cesnet.cz
Delivered-To: lhotka@office2.cesnet.cz
Received: from mail.cesnet.cz (mail.cesnet.cz [195.113.144.234]) by
office2.cesnet.cz (Postfix) with ESMTP id BCEFD2CDE058 for
<lhotka@office2.cesnet.cz>; Fri, 13 Aug 2010 05:31:04 +0200 (CEST)
Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by
mail.cesnet.cz (Postfix) with ESMTP id 8C2A318880D for <lhotka@cesnet.cz>;
Fri, 13 Aug 2010 05:31:02 +0200 (CEST)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com
(Postfix) with ESMTP id A26A73A69C0; Thu, 12 Aug 2010 20:30:22 -0700 (PDT)
X-Original-To: netconf@ietf.org
Delivered-To: netconf@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id 6CB343A68B8; Thu,
12 Aug 2010 20:30:02 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20100813033005.6CB343A68B8@core3.amsl.com>
Date: Thu, 12 Aug 2010 20:30:03 -0700 (PDT)
Cc: netconf@ietf.org
Subject: [Netconf] I-D Action:draft-ietf-netconf-with-defaults-11.txt
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netconf>,
<mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>,
<mailto:netconf-request@ietf.org?subject=subscribe>
Sender: netconf-bounces@ietf.org
Errors-To: netconf-bounces@ietf.org
X-Evolution-Source: imap://lhotka@office2.cesnet.cz/
--NextPart
Content-Transfer-Encoding: 8bit
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration Working Group of the IETF.
Title : With-defaults capability for NETCONF
Author(s) : A. Bierman, B. Lengyel
Filename : draft-ietf-netconf-with-defaults-11.txt
Pages : 31
Date : 2010-08-12
The NETCONF protocol defines ways to read and edit configuration data
from a NETCONF server. In some cases, part of this data may not be
set by the NETCONF client, but rather a default value known to the
server is used instead. In many situations the NETCONF client has a
priori knowledge about default data, so the NETCONF server does not
need to save it in a NETCONF configuration datastore or send it to
the client in a retrieval operation reply. In other situations the
NETCONF client will need this data from the server. Not all server
implementations treat this default data the same way. This document
defines a capability-based extension to the NETCONF protocol that
allows the NETCONF client to identify how defaults are processed by
the server, and also defines new mechanisms for client control of
server processing of default data.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netconf-with-defaults-11.txt
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Message/External-body; name="draft-ietf-netconf-with-defaults-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts"
Content-Type: text/plain
Content-ID: <2010-08-12201519.I-D@ietf.org>
--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf
--NextPart--
--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: problem with I-D announcements
2010-08-16 9:28 problem with I-D announcements Ladislav Lhotka
@ 2010-08-16 14:02 ` Michal Sojka
2010-08-16 17:44 ` Ladislav Lhotka
2010-08-24 12:09 ` Ladislav Lhotka
0 siblings, 2 replies; 4+ messages in thread
From: Michal Sojka @ 2010-08-16 14:02 UTC (permalink / raw)
To: Ladislav Lhotka, notmuch
On Mon, 16 Aug 2010, Ladislav Lhotka wrote:
> I am experiencing a problem with a specific type of messages, namely
> announcements of new Internet drafts. One such message is shown below
> with all headers.
>
> In a search buffer, if I press [RET], the message is shown but the echo
> line says "Couldn't find access type". The [SPC] key then doesn't work,
> only "Beginning of buffer" is displayed in the echo area. Other
> commands, such as adding tags, work as usual.
Greetings to another czech notmuch user :-)
I can confirm the behavior you describe. It seems the error message is
generated by mm-extern-cache-contents in gnus/mm-extern.el. According to
comments in that file, it works with something called
"message/external-body". Currently, I have no clue what external-body
means but your message contains such thing.
My poor Elisp knowledge doesn't allow me to debug the problem, but you
may want to check whether the same problem appears in Gnus and if so,
consult it with Gnus developers.
Cheers,
Michal
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: problem with I-D announcements
2010-08-16 14:02 ` Michal Sojka
@ 2010-08-16 17:44 ` Ladislav Lhotka
2010-08-24 12:09 ` Ladislav Lhotka
1 sibling, 0 replies; 4+ messages in thread
From: Ladislav Lhotka @ 2010-08-16 17:44 UTC (permalink / raw)
To: Michal Sojka, notmuch
On Mon, 16 Aug 2010 16:02:59 +0200, Michal Sojka <sojkam1@fel.cvut.cz> wrote:
> On Mon, 16 Aug 2010, Ladislav Lhotka wrote:
> > I am experiencing a problem with a specific type of messages, namely
> > announcements of new Internet drafts. One such message is shown below
> > with all headers.
> >
> > In a search buffer, if I press [RET], the message is shown but the echo
> > line says "Couldn't find access type". The [SPC] key then doesn't work,
> > only "Beginning of buffer" is displayed in the echo area. Other
> > commands, such as adding tags, work as usual.
>
> Greetings to another czech notmuch user :-)
>
> I can confirm the behavior you describe. It seems the error message is
> generated by mm-extern-cache-contents in gnus/mm-extern.el. According to
> comments in that file, it works with something called
> "message/external-body". Currently, I have no clue what external-body
> means but your message contains such thing.
It's just a pointer to an external resource. The code in mm-extern.el
appears to know about the access type used in that message ("anon-ftp")
but somehow it's unable to figure it out from the MIME header.
>
> My poor Elisp knowledge doesn't allow me to debug the problem, but you
> may want to check whether the same problem appears in Gnus and if so,
> consult it with Gnus developers.
OK, I'll try it.
Thanks, Lada
>
> Cheers,
> Michal
--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: problem with I-D announcements
2010-08-16 14:02 ` Michal Sojka
2010-08-16 17:44 ` Ladislav Lhotka
@ 2010-08-24 12:09 ` Ladislav Lhotka
1 sibling, 0 replies; 4+ messages in thread
From: Ladislav Lhotka @ 2010-08-24 12:09 UTC (permalink / raw)
To: Michal Sojka, notmuch
On Mon, 16 Aug 2010 16:02:59 +0200, Michal Sojka <sojkam1@fel.cvut.cz> wrote:
> On Mon, 16 Aug 2010, Ladislav Lhotka wrote:
> > I am experiencing a problem with a specific type of messages, namely
> > announcements of new Internet drafts. One such message is shown below
> > with all headers.
> >
> > In a search buffer, if I press [RET], the message is shown but the echo
> > line says "Couldn't find access type". The [SPC] key then doesn't work,
> > only "Beginning of buffer" is displayed in the echo area. Other
> > commands, such as adding tags, work as usual.
>
> Greetings to another czech notmuch user :-)
>
> I can confirm the behavior you describe. It seems the error message is
> generated by mm-extern-cache-contents in gnus/mm-extern.el. According to
> comments in that file, it works with something called
> "message/external-body". Currently, I have no clue what external-body
> means but your message contains such thing.
>
> My poor Elisp knowledge doesn't allow me to debug the problem, but you
> may want to check whether the same problem appears in Gnus and if so,
> consult it with Gnus developers.
With my faint Elisp expertise, I tried to investigate the problem a bit
and it seems it is in the notmuch elisp part. The
'mm-extern-cache-contents' function you mentioned
initializes the 'access-type' variable like this:
(let* ((access-type (cdr (assq 'access-type
(cdr (mm-handle-type handle)))))
The 'handle' argument for the problematic message looks like this:
(#<buffer *temp*> ("message/external-body") nil nil nil nil nil nil)
Now, 'mm-handle-type' function extracts the second member from 'handle',
which is ("message/external-body"). Applying 'cdr' to this list yields
necessarily nil and so access-type is always initialized to nil and
consequently the error "Couldn't find access type" is reported.
The ("message/external-body") list is constructed originally in
'notmuch-show-insert-bodypart' function and passed - as 'content-type'
argument - through several stack frames. The use of 'cdr' and 'assq'
functions in the above initialization expression however indicates that
'mm-extern-cache-contents' expects something more complex than just a
simple list.
Perhaps someone with deeper knowledge of notmuch elisp internals could
fix this bug?
Cheers, Lada
>
> Cheers,
> Michal
--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2010-08-24 12:10 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-08-16 9:28 problem with I-D announcements Ladislav Lhotka
2010-08-16 14:02 ` Michal Sojka
2010-08-16 17:44 ` Ladislav Lhotka
2010-08-24 12:09 ` Ladislav Lhotka
Code repositories for project(s) associated with this public inbox
https://yhetil.org/notmuch.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).