On Aug 10, 2012 7:18 PM, "Jameson Graef Rollins" <jrollins at finestructure.net> wrote: > > On Fri, Aug 10 2012, Jani Nikula <jani at nikula.org> wrote: > > How would this work together with something like [1] (rationale in [2])? > > > > [1] id:" ab777cf0fa83778d3399ac52094df9230738819d.1328798471.git.jani at nikula.org" > > [2] id:"cover.1328719309.git.jani at nikula.org" > > > > If you introduce a mechanism to store the state, could it be extended to > > store the state of each individual part? That, in turn, could be used to > > add support for expanding/collapsing each alternative part through the > > buttons (e.g. [ text/html (not shown) ]). Each button could toggle the > > state of the part, and refresh buffer. > > Hey, Jani. Are these patches needed if we have Mark's patch? I would > prefer to see Mark's solution. Since alternative parts are supposed to > be just that, alternative, it seems to me that a solution that would > cycle through display of these parts is really what we want. Is there a > strong need to show multiple alternative parts at the exact same time?
Thanks to broken Microsoft mail clients, I get plenty of invitations that have text/plain and text/calendar alternative parts with information complimenting each other. I usually need to see both (luckily the included html part I can ignore) and it's helpful if I can see them at the same time. In a perfect world neither you or me would need any of this functionality... I suppose cycling through the alternative parts is, in a sense, correct for the reasons you state, we have the code here to do just that, and I can always cook up something for myself. Let's go with this, then, to move forward. BR, Jani. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20120810/486b027d/attachment.html>