From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id AKMhMZRJ+1+mTgAA0tVLHw (envelope-from ) for ; Sun, 10 Jan 2021 18:38:12 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id OBMKLZRJ+19wGwAA1q6Kng (envelope-from ) for ; Sun, 10 Jan 2021 18:38:12 +0000 Received: from mail.notmuchmail.org (nmbug.tethera.net [144.217.243.247]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (2048 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 528B7940105 for ; Sun, 10 Jan 2021 18:38:12 +0000 (UTC) Received: from nmbug.tethera.net (localhost [127.0.0.1]) by mail.notmuchmail.org (Postfix) with ESMTP id CDD5129CF8; Sun, 10 Jan 2021 13:38:05 -0500 (EST) Received: from mail.hostpark.net (mail.hostpark.net [212.243.197.30]) by mail.notmuchmail.org (Postfix) with ESMTPS id 58ED91FBCC for ; Sun, 10 Jan 2021 13:38:03 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.hostpark.net (Postfix) with ESMTP id 90988165E8; Sun, 10 Jan 2021 19:38:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bernoul.li; h= content-type:content-type:mime-version:message-id:date:date :references:in-reply-to:subject:subject:from:from:received :received; s=sel2011a; t=1610303880; bh=MU9hTgQ9qCygaF6Tz+EW/Qa/ FCx4eBT9QHhAZI9u4PY=; b=unCHVYN514HOX/TcuB9QtUNYkQlTE1vpZqOLEm2K xAl9AS2n0iVftoAKgwiucET1fc6/vHmQrzx8axcdJutesAAUJiqe4Vy4Hhd4aq7F sl27AaX8GFxignU9xMZ7oMQTZ/U7/vgZErVdQUG+VQFnfge9r3quIIfA+XaJVFr+ Xv8= X-Virus-Scanned: by Hostpark/NetZone Mailprotection at hostpark.net Received: from mail.hostpark.net ([127.0.0.1]) by localhost (mail0.hostpark.net [127.0.0.1]) (amavisd-new, port 10224) with ESMTP id 5cOgPk2q76M4; Sun, 10 Jan 2021 19:38:00 +0100 (CET) Received: from customer (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.hostpark.net (Postfix) with ESMTPSA id 5F4EC165B8; Sun, 10 Jan 2021 19:38:00 +0100 (CET) From: Jonas Bernoulli To: Daniel Kahn Gillmor , Tomi Ollila , Notmuch Mail Subject: Re: [PATCH] emacs/notmuch-show: Work around errors where a part lacks a content-type In-Reply-To: <87y2h76o3a.fsf@fifthhorseman.net> References: <87wnwu8tzf.fsf@fifthhorseman.net> <20210103183154.1207696-1-dkg@fifthhorseman.net> <87im8c9zru.fsf@bernoul.li> <87y2h76o3a.fsf@fifthhorseman.net> Date: Sun, 10 Jan 2021 19:38:00 +0100 Message-ID: <87v9c4tz7b.fsf@bernoul.li> MIME-Version: 1.0 Message-ID-Hash: DFZ46PRLL5FWCO3WNOXCEZZFBRZUNXRN X-Message-ID-Hash: DFZ46PRLL5FWCO3WNOXCEZZFBRZUNXRN X-MailFrom: jonas@bernoul.li X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-notmuch.notmuchmail.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header X-Mailman-Version: 3.2.1 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -1.09 Authentication-Results: aspmx1.migadu.com; dkim=fail (body hash did not verify) header.d=bernoul.li header.s=sel2011a header.b=unCHVYN5; dmarc=none; spf=pass (aspmx1.migadu.com: domain of notmuch-bounces@notmuchmail.org designates 144.217.243.247 as permitted sender) smtp.mailfrom=notmuch-bounces@notmuchmail.org X-Migadu-Queue-Id: 528B7940105 X-Spam-Score: -1.09 X-Migadu-Scanner: scn0.migadu.com X-TUID: aAgImUiSU5Xa I accidentally responded off-list. Here is (part of) Daniel's response to that message: On Wed 2021-01-06 18:48:09 +0100, Jonas Bernoulli wrote: > Okay, I'll prepare a patch that does that. Thanks! > I wasn't so much worried having to deal with this in multiple places in > elisp--that's quite manageable--but about all the other front-ends that > will also have to discover and address this issue over time. yep, makes sense. This might well be a "both and" situation instead of an "either or".