Mark Walters <markwalters1009@gmail.com> 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