On Fri, 10 Aug 2012, Jani Nikula <jani@nikula.org> wrote:
> On Aug 10, 2012 7:18 PM, "Jameson Graef Rollins" <jrollins@finestructure.net>
> wrote:
>>
>> On Fri, Aug 10 2012, Jani Nikula <jani@nikula.org> wrote:
>> > How would this work together with something like [1] (rationale in [2])?
>> >
>> > [1] id:"
> ab777cf0fa83778d3399ac52094df9230738819d.1328798471.git.jani@nikula.org"
>> > [2] id:"cover.1328719309.git.jani@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.

Hi

I am not sure I agree: I think maybe toggling parts is better. Either
the parts contain the same information and then the current behaviour is
probably fine, or they are not in which case we might want to see both
at once

Best wishes

Mark