From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id AA36F431FB6 for ; Fri, 19 Oct 2012 09:36:33 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.776 X-Spam-Level: X-Spam-Status: No, score=-0.776 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HS_INDEX_PARAM=0.023, RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuwMOSeZbhHR for ; Fri, 19 Oct 2012 09:36:33 -0700 (PDT) Received: from mail-vb0-f53.google.com (mail-vb0-f53.google.com [209.85.212.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id F11F8431FAE for ; Fri, 19 Oct 2012 09:36:32 -0700 (PDT) Received: by mail-vb0-f53.google.com with SMTP id fc21so715065vbb.26 for ; Fri, 19 Oct 2012 09:36:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:in-reply-to:references:user-agent:date:message-id :mime-version:content-type; bh=FL+NLvrYWzganYQhz/+4PHAe7lOrthGsOWAPFykAvzA=; b=TTdH7xc+7xr2l+nW1mcoACoR9uaX0T1+NDkCm4fUig5WZW7XQ08YYL9Vg/l325CQjI fx6K3wJ0gGmbm59svbdzEm+zlH9VawSG/P3dcND8sAQ8E98e6D55lnHHmG51m5Ud0XGq PpRrHimlk3VAP8QCV0E1b+i7et/Mh/SnGYA/i4AY70QCqoXgyj+bqMPUnS5JjUfmPqjl yrw18vSxSFnFCVSQoZ8a0gqZiwKFJ8rwPVC6BVJyhO3N7UcD3CkOR3weja3j1GWxzWWb fO02VrTXSYOMmYFL1RqawTKB1XiRkw+1lijN118KLQljeEvgaEDtqgMNYofFGqoiMbDA tlLQ== Received: by 10.52.27.82 with SMTP id r18mr1818894vdg.120.1350664592262; Fri, 19 Oct 2012 09:36:32 -0700 (PDT) Received: from smtp.gmail.com (p70-80.acedsl.com. [66.114.70.80]) by mx.google.com with ESMTPS id w17sm1921449vdf.16.2012.10.19.09.36.30 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 19 Oct 2012 09:36:30 -0700 (PDT) From: Ethan Glasser-Camp To: Mark Walters , Jameson Graef Rollins , Jani Nikula , notmuch@notmuchmail.org Subject: Re: [PATCH v2] emacs: add function to toggle display of all multipart/alternative parts In-Reply-To: <87r4rf9q8x.fsf@qmul.ac.uk> References: <1339775751-18002-1-git-send-email-jani@nikula.org> <87zk80gvmb.fsf@servo.finestructure.net> <87pq8vokmp.fsf@qmul.ac.uk> <87ipcrvlcw.fsf@servo.finestructure.net> <87r4rf9q8x.fsf@qmul.ac.uk> User-Agent: Notmuch/0.14+45~g6ea9330 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu) Date: Fri, 19 Oct 2012 12:36:26 -0400 Message-ID: <87pq4e771x.fsf@betacantrips.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 16:36:33 -0000 Mark Walters writes: > Some messages are sent as multipart/alternative but the alternatives > contain different information. This allows the user to cycle which > part to view. By default this is bound to 'W'. > --- > > This version at least uses the notmuch escaping for message-id which > makes me a bit happier: it probably doesn't have any nasty security > flaws. I do still feel that the lisp is a bit ugly though. For what it's worth, I don't feel that this code is horrible. It seems like there remain design decisions to be made about how notmuch show "ought" to handle multipart/alternatives, but I can at least comment on this code. First, the use of a plist looks fine to me because most of the time it's going to have length 0. At most it will have one entry per message -- a few hundred. So I'm not worried about efficiency concerns. > (defcustom notmuch-show-stash-mlarchive-link-alist > '(("Gmane" . "http://mid.gmane.org/") > ("MARC" . "http://marc.info/?i=") > @@ -536,9 +540,19 @@ message at DEPTH in the current thread." > > (defun notmuch-show-insert-part-multipart/alternative (msg part content-type nth depth declared-type) > (notmuch-show-insert-part-header nth declared-type content-type nil) > - (let ((chosen-type (car (notmuch-multipart/alternative-choose (notmuch-show-multipart/*-to-list part)))) > - (inner-parts (plist-get part :content)) > - (start (point))) > + (let* ((chosen-nth (or (lax-plist-get notmuch-show-message-multipart/alternative-display-part > + (notmuch-id-to-query (plist-get msg :id))) 0)) > + (chosen-type (nth chosen-nth > + (notmuch-multipart/alternative-choose (notmuch-show-multipart/*-to-list part)))) > + (inner-parts (plist-get part :content)) > + (start (point))) Changing let to let* makes me the slightest bit uneasy, although I'm not sure I could explain why. It would be nice if you could wrap the manipulation of notmuch-show-message-multipart/alternative-display-part in functions, ideally with names that are shorter than the variable they manipulate. Specifically, I think the definition of chosen-nth (which is almost repeated below) could be its own function, something like (notmuch-show-message-current-multipart msg), which could take a msg-id or a plist and do the plist-get and id-to-query that you do here. > + ;; If we have run out of possible content-types restart from the beginning > + (unless chosen-type > + (setq chosen-type (car (notmuch-multipart/alternative-choose (notmuch-show-multipart/*-to-list part)))) > + (setq notmuch-show-message-multipart/alternative-display-part > + (lax-plist-put notmuch-show-message-multipart/alternative-display-part > + (notmuch-id-to-query (plist-get msg :id)) 0))) > + > ;; This inserts all parts of the chosen type rather than just one, > ;; but it's not clear that this is the wrong thing to do - which > ;; should be chosen if there are more than one that match? > @@ -942,6 +956,16 @@ message at DEPTH in the current thread." > "Not processing cryptographic MIME parts.")) > (notmuch-show-refresh-view)) > > +(defun notmuch-show-cycle-message-multipart () > + "Cycle which part to display of a multipart messageToggle the display of non-matching messages." This docstring is broken. > + (interactive) > + (let* ((msg-id (notmuch-show-get-message-id)) > + (next-part (1+ (or (lax-plist-get notmuch-show-message-multipart/alternative-display-part msg-id) 0)))) > + (setq notmuch-show-message-multipart/alternative-display-part > + (lax-plist-put notmuch-show-message-multipart/alternative-display-part msg-id next-part)) > + (message "Cycling multipart/alternative for current message") > + (notmuch-show-refresh-view))) Maybe move the reset-and-go-back-to-zero behavior to this function instead of in the display function. This opens you up to weird situations if one of the multipart/alternatives should disappear from a message or if some other function should change the alternative on display for a given message, but both of these seem unlikely to me.. Ethan