New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better support for multipart/alternative? #587

Closed
mrzool opened this Issue May 17, 2017 · 41 comments

Comments

Projects
None yet
9 participants
@mrzool

mrzool commented May 17, 2017

I'm new to mutt and would like to use it for all my emails. I have spent the last couple of days trying to set up a sensible environment, but I'm hitting my head against (several) walls.

The struggle started when I realized that sending emails in plain text is not viable anymore nowadays, because hard line breaks render the text hardly readable on small screens, and I don't want my emails to be ugly and hardly readable. There's a couple of suggestions as to how to work around this with the unlucky standard format=flowed (set text_flowed in mutt) and some ad-hoc setting in Vim (setlocal fo=aw). I soon realized that this doesn't work in several major email clients. Text looking fine in Gmail web interface looked terrible in Outlook. format=flowed is thus not a viable solution to this issue.

It appears that the only way to get nicely wrapped, responsive text in emails is (horrors) marking it up with HTML. So I wrote a macro to convert the body of the message in the 'compose' window to HTML and change the Content-Type to text/html just before sending — I use Pandoc, which has the nice side-effect of allowing me to use Markdown in my emails. So far so good, things are working and I'm happy. But what about email clients that are unable to display HTML? I don't want to give up plain text wholesale, I want my emails to be as accessible as possible.

The standard solution to this is to use Content-Type: multipart/alternative and embed two versions of the same text in the body, one in plain text and one in HTML, delimiting the regions through a string named boundary:

Content-Type: multipart/alternative; boundary="myboundary"

So I wrote a (rudimentary) shell script that takes the email body, converts it as needed, sets the various boundaries between regions, and outputs a new body readily formatted for multipart/alternative. I integrated the script into my mutt macro and did some testing.

Well, nothing works as expected.

I write an email containing the following:

First paragraph.

Second paragraph.

Third paragraph.

Then I close and drop into the 'Compose' window. I filter the body through my script with F and I get this back, as expected:

--myboundary
Content-Type: text/plain; charset=utf-8

First paragraph. 
 
Second paragraph. 
 
Third paragraph. 

--myboundary
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html code omitted>

--myboundary--

Then I hit ^T and change Content-Type to multipart/alternative. All looks good. I hit Enter to inspect the attachment. All looks good. I hit Q to go back to 'Compose'. Mutt changed the content type back to text/plain.

I change the content type again. This time I send the message without inspecting the attachment. Mutt sends the email. I receive it in Gmail with the expected content type, an empty noname attachment and an empty body.

I try again. This time I change content type before converting the body. Same behavior. Every time I inspect the attachment Mutt changes the content type back to text/plain. If I send the email, I get an empty body and an empty noname attachment.

Is this a bug? Expected behavior? How can I send a multipart/alternative message using Mutt? Is support for this content type lacking? Can it be improved?

@gahr

This comment has been minimized.

Member

gahr commented May 17, 2017

I don't see any native support for this, unfortunately. As a workaround, I would tried setting

my_hdr Content-Type: multipart/alternative; boundary="myboubdary"

in .muttrc.

I'm not at the keyboard now so I can't really test it.

@mrzool

This comment has been minimized.

mrzool commented May 17, 2017

Thanks @gahr, I'll try that as soon as I'm back from a trip in about a week and get back to you.

@guyzmo

This comment has been minimized.

Contributor

guyzmo commented May 18, 2017

this is actually a project I've been working on for some time, and wrote a tool to convert my outgoing mail in HTML once I hit send. But that was wrong.

Even though I did not try it, I think @gahr's suggestion won't work, because mutt is managing the multipart header for the attachments, and adding twice that header could lead to a 🔥

@guyzmo guyzmo closed this May 18, 2017

@guyzmo guyzmo reopened this May 18, 2017

@guyzmo

This comment has been minimized.

Contributor

guyzmo commented May 18, 2017

I tried doing several huge macro hacks to generate an HTML attachment out of the full text one (using pandoc, because, yes, pandoc is ♥) and that alone was painful (which is one of the reasons I wrote the Lua scripting extension).

And then converting the mail to multipart is still an issue I'm thinking about. The way I think would be a great UX would be to tag the parts we want to be the alternatives and mark them as such.

(PS: sorry, had the cat walk over my hands and the trackpad and close the issue… I mean he really did it 😼)

@mrzool

This comment has been minimized.

mrzool commented May 25, 2017

Indeed @guyzmo, @gahr's suggestion doesn't work, that just adds a second header to the message, leaving the original text/plain header intact.

I honestly think this is a significant shortcoming of Mutt, and would love to see it addressed in some way. Since plain text email are no longer a sensible choice for many (our emails get read on a plethora of different devices), it would be great to have just a bit of added flexibility in this sense.

If I were able to at least set the headers myself without Mutt messing with it afterwards, then I could write my own script to format the body properly and handle various scenarios (multipart/alternative for simple messages, multipart/mixed with embedded multipart/alternative for messages with additional attachments). Of course, there are several MUAs out there which handle this natively and automatically, but I really want to use Mutt :)

Any feedback on this?

@guyzmo

This comment has been minimized.

Contributor

guyzmo commented May 25, 2017

actually, the multipart/alternative has been a huge troll 15 years ago, and I don't remember all the details, just that a huge part of the community was, then, against that. There's a standard way of overcoming this, though, it's to use the text_flowed setting which is supported by Mail.app or Gmail.

Whether doing the alternative support as a script or as a patch will really depend on how much change and how complex that will be (basically, if to add multipart/alternative support, one shall only expose structs and functions, that'd be a good way to go, if actually patching is needed… then it's not).

@mrzool

This comment has been minimized.

mrzool commented May 26, 2017

If text_flowed were a reliable way to fix this I'd be very happy to settle for plain text emails without a second thought...sadly it's not, as I mentioned above. Proper implementation of this standard seems to be arduous, many major clients don't support it. That's why I'm looking into alternatives.

Yes, I've sensed hostility to supporting multipart/alternative in some old discussions on the matter, but no substantial argument was given against it as far as I can recall, other than "HTML in emails is bad and we shouldn't encourage its use". The thing is, 15 years after, HTML emails are everywhere, used by everyone, universally supported, guaranteed to be properly displayed by every client on every device, and solve all the problems I have with plain text emails.

At the end of the day it all boils down to this: In the current state, an email sent by Mutt has 100% chance to look like crap on a phone. Let that sink in.

In 2017, if there's a new trick an old dog needs to be taught, that's proper support of current accessibility standards, or at least enough flexibility to let users compensate for the lack thereof.

@guyzmo

This comment has been minimized.

Contributor

guyzmo commented May 26, 2017

Sure, I share your frustration about this, and I'm saddened to see that HTML mail is everywhere, and that we get mandrillapp.com (or the others alike) links in not only newsletters but anybody's mail, with those 1px image just to track when you're opening the mail. And then you've got all those firms that specialise in 'e-mail design'. Unreadable, ugly and tracking is the new standard, and that's sickening ¯_(ツ)_/¯

So, in the end, let's focus on how/where to solve this. I'm going to have a look at that when I'll have the time to, if you want as well, you're welcome to do so! You can also join the IRC channel #neomutt on freenode 😉 It's likely to be a non-trivial change, and finding the simplest, less painful, yet elegant way to implement this won't be easy.

In terms of UX, what I've said is that we need to keep it simple, in the compose view, tag two attachments, and hit some tag-makealternative function with a binding, to make them multipart/alternative. Then a simple visual queue in the listing to show the "default' part, and the alternatives.

Then with a bit of macro magic (or scripting) you can automize the steps of select the body part, convert it as html into another part, select them both, make them alternatives, with the text/plain as default, and eventually send it.

@mrzool

This comment has been minimized.

mrzool commented May 30, 2017

I apologize for the late reply, I've been busy after coming back home. I share your aversion to HTML email and its misuse, especially when plain text email would do just fine. But I have tried long and hard to get acceptable results using plain text emails (hell, I use plain text for everything) and things simply don't work as they should. The specifications are too old (hard line breaks instead of letting the receiving client deal with the wrapping), standards to work around their shortcomings (format=flowed) are ill-supported. If the the price to have a sane and consistent behavior across all clients and devices is to send out HTML, so be it! I'm not ideologically against it and I don't see anything inherently wrong with it if one doesn't start misusing it.

What surprises me is the lack of reactions and discussion around the topic. Am I the only one with this issue? Do people actually use Mutt as their main MUA, knowing that their email might come horribly scrambled to the receiver? Are folks fine with that? I would never trust Mutt in its current state to send out a job application or any important email.

I'd love to look into this, @guyzmo, but I'm not a C programmer nor an email expert, just a humble user trying to send some emails. I do thank you profusely for hearing me out in the first place, though!

@somini

This comment has been minimized.

Member

somini commented May 30, 2017

I use mutt as my main MUA, but I don't send that much mail and mostly keep it short. I'm not against writing markdown and using pandoc to convert it to html, but it's not an easy task to mangle the current mutt into doing this.
Now with the Lua API it should be possible to do this in a non insane way, but it's at least a weekend of work to get a prototype going. We are all volunteers, that's why the default response is helping the users help themselves.

@gahr

This comment has been minimized.

Member

gahr commented May 30, 2017

I don't think talking mutt into producing html emails is a solution for this problem. It would just hide the issue for MUAs that do support html but do not handle the flowed format specs of MIME.

Edit: inadvertently pushed Comment too early, continuing below:

Doing so would just turn the problem the other way around: MUAs supporting HTML would display your email just fine, while text-only MUAs that do support format=flowed will display crap.

Just thinking.. is this really a mutt issue?

@guyzmo

This comment has been minimized.

Contributor

guyzmo commented May 31, 2017

Well, currently my own work around is that when I send mails to people I know will read my mail on crappy UIs (phones, outlook…), I join (J) the paragraphs into long lines. Then it's ugly for me, but fine for them. No need for flowed or anything.

When I'm talking with people that have a proper MUA, or should know how to configure (and chose) a decent MUA, then I do proper line breaks. And formatting.

My goal is that I like to enforce presentation in my mails, doing some simple ASCII art or lines alignment, and people tend to read their mail with a variable width font. My personal take on using multipart/alternative would be to enforce a stylesheet that would force people to read my mail the way I designed it, and with a proper fixed-width font… while keeping the text/plain alternative clean and sane.

So is it a mutt issue? I don't think so, as it's been discarded as being an issue for a couple of decades. But it's definitely a feature request, which I hope we'll be able to implement with minimal changes to mutt.

@somini

This comment has been minimized.

Member

somini commented May 31, 2017

This is not really producing HTML email, the feature request is authoring multipart/alternative emails. Mutt can read them just fine, but you can't create them.

@gahr

This comment has been minimized.

Member

gahr commented May 31, 2017

If this boils down to having mutt respect and work with what I suggested earlier, namely
my_hdr Content-Type: multipart/alternative; boundary="myboubdary"
I'm all for it :) Anything further than that (automatic format conversion using pandoc, automatic generation of text/plain from html, ...) is out of scope, IMHO.

@mrzool

This comment has been minimized.

mrzool commented May 31, 2017

@somini:

I'm not against writing markdown and using pandoc to convert it to html, but it's not an easy task to mangle the current mutt into doing this.

Actually I managed to get this working with a fairly simple macro:

macro compose \; "F pandoc --smart -s -f markdown -t html<enter>y^T^Utext/html; charset=utf-8<enter>"

Problems arise only when turning this up a notch and trying to compose an email which has both text/plain and text/html alternatives and multipart/alternative as content type.

@gahr

It would just hide the issue for MUAs that do support html but do not handle the flowed format specs of MIME.

Again, producing HTML emails it's not the issue, that works just fine with the Pandoc macro.

MUAs supporting HTML would display your email just fine, while text-only MUAs that do support format=flowed will display crap.

That's exactly what multipart/alternative would solve! Sorry if the point got lost in my overly verbose comments.

As a side note, I had noticed that Mutt already has some awareness of multipart/alternative. When trying to send a message with multipart/alternative set, but no boundary, Mutt gives this error:

No boundary parameter found!

Not sure what to make of that, but it gave me hope when I was desperately trying to get this working.

@mrzool

This comment has been minimized.

mrzool commented May 31, 2017

@gahr

Anything further than that (automatic format conversion using pandoc, automatic generation of text/plain from html, ...) is out of scope, IMHO.

I'm not suggesting that this ability should be built into Mutt, far from it! Just that a user should be able to filter an attachment using his/her own scripts (already possible, it's a working feature) and set the desired content/type (which is a simple string of text). That's just interface scriptability, which is one of the main points of using Mutt.

@gahr

This comment has been minimized.

Member

gahr commented May 31, 2017

I am able to force the content type using the, surprise, content_type setting:

:set content_type="multipart/alternative; boundary=\"__bound__\""

But so far I haven't been able to actually produce and send a multipart email. Might be a good start, though.

@mrzool

This comment has been minimized.

mrzool commented May 31, 2017

Yep, that's exactly the issue. Filtering attachments through scripts works, setting a multipart/alternative content type works (though Mutt changes it back to text/plain after you view the attachment with <Enter>...bug?), yet the email arrives empty and with a noname attachment containing nothing.

Content-Type: multipart/alternative; boundary="myboundary"
Content-Disposition: inline
In-Reply-To: <CA+OhsQKsbpSbC8KEWYGfE_1C+Mu=aKFK9tx80sqd=4XQ_REnzg@mail.gmail.com>
User-Agent: Mutt/1.8.2 (2017-04-18)

--myboundary--

Seems like this is very close to working, but something interferes while sending.

@gahr

This comment has been minimized.

Member

gahr commented May 31, 2017

Alright, I now understand the issue as a whole. Sorry if it took a few iterations ;)

@gahr

This comment has been minimized.

Member

gahr commented May 31, 2017

Ok, so this is how you send a multipart email with mutt:

  1. prepare your parts (text, html) as separate files - you are going to add those as attachments;
  2. set your content_type to multipart/alternative - you don't need to specify a boundary;
  3. compose a new email - the body doesn't matter;
  4. add the files that you prepared in step 1. as attachments
  5. modify the Content-Type of each attachment as needed (highlight the attachment, then exec edit-type or Ctrl-T) - if you named your files with proper extensions, mutt should be able to figure it out itself
  6. remove attachment 1, that is, the main body
  7. send

Edit: not quite. This results in a multipart/mixed.

@guyzmo

This comment has been minimized.

Contributor

guyzmo commented May 31, 2017

to be clear, @gahr, the html thing not being part of mutt is what I'm advocating, and is one of the reasons I wanted Lua scripting (it's possible using macros, but my experiments made me endup doing a way too complex macro for that), and I've started doing it. We all agree that we don't want to see anything related to HTML within Mutt. Never. It shall happen in filters, scripts, anywhere else.

About the multipart, what needs to happen is simply have the possibility to select (T) two or more attachments in compose screen, and mark them as multipart/alternative, and done. I think hacking with the :set content_type of the mail is wrong, because you might want to have a mail structure such as:

    multipart/mixed (mail)
        multipart/alternative (attachment #1)
            text/plain (#1.1)
            text/html (#1.2)
            text/calendar (#1.3)
        application/ics (attachment #2)
        application/pdf (attachment #3)
        image/jpeg (attachment #4)

you might also have a visual feedback to see when, and which attachments are part of an alternative, maybe alike the attachment view for multipart alternative:

 I     1 <no description>           [multipa/alternativ, 7bit, 61K] 
 I     2 ├─><no description>      [text/plain, base64, utf-8, 4.7K] 
 I     3 ├─><no description>        [text/html, quoted, utf-8, 54K] 
 I     4 └─><no description>     [text/calendar, 7bit, utf-8, 1.7K] 
 A     5 invite.ics                     [applica/ics, base64, 2.3K] 

I guess that's a long shot and maybe we should split the work in small increments toward proper compose support of the multipart/alternative.

@guyzmo

This comment has been minimized.

Contributor

guyzmo commented May 31, 2017

Ok, so this is how you send a multipart email with mutt:

ok, so that's a start, we just need to make it not a huge absurd hack (editing parts from elsewhere, removing main attachments, changing the whole content-type etc.).

@gahr

This comment has been minimized.

Member

gahr commented May 31, 2017

I just found this. Has anybody seen / tried it?

@gahr

This comment has been minimized.

Member

gahr commented May 31, 2017

@guyzmo everything you said is correct. We might want to try to import that patch and see if it's sufficient.

@guyzmo

This comment has been minimized.

Contributor

guyzmo commented May 31, 2017

OMG ♥♥♥ gotta try that 😀

@mrzool

This comment has been minimized.

mrzool commented May 31, 2017

@gahr We're definitely getting there, but, as you noted, using your method the email gets sent as multipart/mixed, a boundary gets inserted automatically by Mutt, but there's no nested multipart/alternative, so both the attachments end up displayed in the email body one after the other (also, one needs to change disposition of the attachments from attachment to inline with ^D before sending, otherwise both files get sent as external attachments).

I rejoice, however, in finding confirmation that a support for multipart messages is already present in Mutt! The automatic insertion of a boundary is the definitive proof. Maybe implementing better support will not be so hard after all? All the pieces seem to be already there.

@mrzool

This comment has been minimized.

mrzool commented Jun 7, 2017

Any luck with that patch @guyzmo?

flatcap added a commit that referenced this issue Oct 16, 2017

Initial support for multipart/alternative
This is still WIP, mutt segfaults right after sending the email.

This is the work of @oblitium, based on this unattributed patch:
https://github.com/altercation/arch-packages/blob/master/mutt-dgc-hg/dgc.groupalts

References #587

flatcap added a commit that referenced this issue Oct 26, 2017

Initial support for multipart/alternative
This is still WIP, mutt segfaults right after sending the email.

This is the work of @oblitium, based on this unattributed patch:
https://github.com/altercation/arch-packages/blob/master/mutt-dgc-hg/dgc.groupalts

References #587
@libBletchley

This comment has been minimized.

Member

libBletchley commented Nov 17, 2017

@mrzool

I share your aversion to HTML email and its misuse, especially when plain text email would do just fine. But I have tried long and hard to get acceptable results using plain text emails (hell, I use plain text for everything) and things simply don't work as they should.

HTML is a bit extreme. Did you try text/enriched? I've used text/enriched with good results. I didn't test it extensively, but using Gnus (an emacs mail client) to compose an enriched text message and sending it to an MS Outlook user worked well. In that case, MS Outlook converted the text/enriched email to text/html before presenting to the user. I was happy that all the HTML nonsense was isolated on the recipient's side.

So this way I get the formatting I need without touching HTML and all the dodginess it brings -- not to mention no self-respecting nerd would send an HTML email. If you use text/enriched instead of text/html, you get to keep your nerd badge. RTF for text/enriched is here.

@flatcap
The mutt can learn some new tricks from Gnus
Gnus has a very flexible and intuitive way of composing MIME parts. It would be useful if mutt would mirror the Gnus approach and syntax. Users simply insert tags in their message that Gnus interprets and generates all the proper headers from. So this is what it looks like in the editor when composing:

<#multipart type=alternative>
<#part type="text/plain" disposition=inline>
This is the plain text body.
<#/part>
<#part type="text/enriched" disposition=inline>
This is the <bold>enriched</bold> <color><blue>text</blue></color> <italic>body</italic>.
<#/part>
<#/multipart>

The user need not remember those strings either.. there are keybindings to insert the templates.

@mrzool

This comment has been minimized.

mrzool commented Nov 17, 2017

@libBletchley Thanks for your suggestion, but my point here is not about formatting in emails, nor hyperlinking, embedded images and least of all about fancy CSS (as somebody brought up a while ago in here in a now deleted comment). As explained above, literally my only issue with plain text emails are hard line breaks that render emails hardly readable on the (now ubiquitous) small display.

It's the usability issue that I'd like to see addressed with multipart/alternative support. Not the lack of formatting or other trivialities.

For the record, I've found a workaround for this, and I'm happily sending plain text emails around. The trick is to change the encoding of the email to quoted-printable. This effectively solves the problem of hard wrapping and seems to be well supported by most MUAs (as opposed to format=flowed, which would admittedly be the most elegant solution).

So far so good, the text gets a bit mangled but the receiving end sees only nice, soft-wrapped plain text. If anyone is aware of any drawback with this method, or any reason why I shouldn't do that, I'd love to hear about it!

@libBletchley

This comment has been minimized.

Member

libBletchley commented Nov 17, 2017

@mrzool

my only issue with plain text emails are hard line breaks that render emails hardly readable on the (now ubiquitous) small display.

I understand. That's why I suggested text/enriched. It gives the effect of format=flowed without actually using that parameter. If you have a better workaround, great. I didn't follow the whole thread in detail to the end, but I saw that text/html was your apparent hack for word-wrapping, in which case text/enriched is better for that minimal purpose. If you find yourself using text/html and you don't need all the frills that HTML brings, that's precisely when text/enriched is appropriate.

@mrzool

This comment has been minimized.

mrzool commented Nov 17, 2017

@libBletchley

That's why I suggested text/enriched. It gives the effect of format=flowed without actually using that parameter.

That sounds really interesting and might be a better solution than quoted-printable. I will look into it, many thanks for bringing this up!

flatcap added a commit that referenced this issue Nov 17, 2017

Initial support for multipart/alternative
This is still WIP, mutt segfaults right after sending the email.

This is the work of @oblitium, based on this unattributed patch:
https://github.com/altercation/arch-packages/blob/master/mutt-dgc-hg/dgc.groupalts

References #587

flatcap added a commit that referenced this issue Nov 27, 2017

Initial support for multipart/alternative
This is still WIP, mutt segfaults right after sending the email.

This is the work of @oblitium, based on this unattributed patch:
https://github.com/altercation/arch-packages/blob/master/mutt-dgc-hg/dgc.groupalts

References #587

flatcap added a commit that referenced this issue Nov 30, 2017

Initial support for multipart/alternative
This is still WIP, mutt segfaults right after sending the email.

This is the work of @oblitium, based on this unattributed patch:
https://github.com/altercation/arch-packages/blob/master/mutt-dgc-hg/dgc.groupalts

References #587

flatcap added a commit that referenced this issue Jan 2, 2018

Initial support for multipart/alternative
This is still WIP, mutt segfaults right after sending the email.

This is the work of @oblitium, based on this unattributed patch:
https://github.com/altercation/arch-packages/blob/master/mutt-dgc-hg/dgc.groupalts

References #587

flatcap added a commit that referenced this issue Jan 21, 2018

Initial support for multipart/alternative
This is still WIP, mutt segfaults right after sending the email.

This is the work of @oblitium, based on this unattributed patch:
https://github.com/altercation/arch-packages/blob/master/mutt-dgc-hg/dgc.groupalts

References #587

flatcap added a commit that referenced this issue Feb 16, 2018

Initial support for multipart/alternative
This is still WIP, mutt segfaults right after sending the email.

This is the work of @oblitium, based on this unattributed patch:
https://github.com/altercation/arch-packages/blob/master/mutt-dgc-hg/dgc.groupalts

References #587

flatcap added a commit that referenced this issue Feb 24, 2018

Initial support for multipart/alternative
This is still WIP, mutt segfaults right after sending the email.

This is the work of @oblitium, based on this unattributed patch:
https://github.com/altercation/arch-packages/blob/master/mutt-dgc-hg/dgc.groupalts

References #587

flatcap added a commit that referenced this issue Mar 9, 2018

Initial support for multipart/alternative
This is still WIP, mutt segfaults right after sending the email.

This is the work of @oblitium, based on this unattributed patch:
https://github.com/altercation/arch-packages/blob/master/mutt-dgc-hg/dgc.groupalts

References #587

walkerlala added a commit to walkerlala/neomutt that referenced this issue Mar 11, 2018

support for multipart/alternative and multipart/mixed
This work is based on commit 5b4f7a1 from @somini and was discussed
at <neomutt#587>. As of now, one can
tag entries in the compose menu and use <group-alternatives> to group
those entries into one. If all the entries are tagged (including the
fundamental part), then the email become a multipart/alternative one,
otherwise it becomes a multipart/mixed one.

There is some weird things to be noted, though: when postponning a
multipart/alternative mail and then recall it, those entries get
splitted up. This does not occurred for multipart/mixed mails.

flatcap added a commit that referenced this issue Mar 12, 2018

Initial support for multipart/alternative
This is still WIP, mutt segfaults right after sending the email.

This is the work of @oblitium, based on this unattributed patch:
https://github.com/altercation/arch-packages/blob/master/mutt-dgc-hg/dgc.groupalts

References #587

flatcap added a commit that referenced this issue Mar 12, 2018

support for multipart/alternative and multipart/mixed
This work is based on commit 5b4f7a1 from @somini and was discussed
at <#587>. As of now, one can
tag entries in the compose menu and use <group-alternatives> to group
those entries into one. If all the entries are tagged (including the
fundamental part), then the email become a multipart/alternative one,
otherwise it becomes a multipart/mixed one.

There is some weird things to be noted, though: when postponing a
multipart/alternative mail and then recall it, those entries get
split up. This does not occurred for multipart/mixed mails.

flatcap added a commit that referenced this issue Mar 24, 2018

Initial support for multipart/alternative
This is still WIP, mutt segfaults right after sending the email.

This is the work of @oblitium, based on this unattributed patch:
https://github.com/altercation/arch-packages/blob/master/mutt-dgc-hg/dgc.groupalts

References #587

flatcap added a commit that referenced this issue Mar 24, 2018

support for multipart/alternative and multipart/mixed
This work is based on commit 5b4f7a1 from @somini and was discussed
at <#587>. As of now, one can
tag entries in the compose menu and use <group-alternatives> to group
those entries into one. If all the entries are tagged (including the
fundamental part), then the email become a multipart/alternative one,
otherwise it becomes a multipart/mixed one.

There is some weird things to be noted, though: when postponing a
multipart/alternative mail and then recall it, those entries get
split up. This does not occurred for multipart/mixed mails.

flatcap added a commit that referenced this issue Mar 27, 2018

Initial support for multipart/alternative
This is still WIP, mutt segfaults right after sending the email.

This is the work of @oblitium, based on this unattributed patch:
https://github.com/altercation/arch-packages/blob/master/mutt-dgc-hg/dgc.groupalts

References #587

flatcap added a commit that referenced this issue Mar 27, 2018

support for multipart/alternative and multipart/mixed
This work is based on commit 5b4f7a1 from @somini and was discussed
at <#587>. As of now, one can
tag entries in the compose menu and use <group-alternatives> to group
those entries into one. If all the entries are tagged (including the
fundamental part), then the email become a multipart/alternative one,
otherwise it becomes a multipart/mixed one.

There is some weird things to be noted, though: when postponing a
multipart/alternative mail and then recall it, those entries get
split up. This does not occurred for multipart/mixed mails.

flatcap added a commit that referenced this issue Apr 25, 2018

Initial support for multipart/alternative
This is still WIP, mutt segfaults right after sending the email.

This is the work of @oblitum.

References #587

flatcap added a commit that referenced this issue Apr 25, 2018

support for multipart/alternative and multipart/mixed
This work is based on commit 5b4f7a1 from @somini and was discussed
at <#587>. As of now, one can
tag entries in the compose menu and use <group-alternatives> to group
those entries into one. If all the entries are tagged (including the
fundamental part), then the email become a multipart/alternative one,
otherwise it becomes a multipart/mixed one.

There is some weird things to be noted, though: when postponing a
multipart/alternative mail and then recall it, those entries get
split up. This does not occurred for multipart/mixed mails.

flatcap added a commit that referenced this issue Apr 25, 2018

Initial support for multipart/alternative
This is still WIP, mutt segfaults right after sending the email.

This is the work of @oblitum.

References #587

flatcap added a commit that referenced this issue Apr 25, 2018

support for multipart/alternative and multipart/mixed
This work is based on commit 5b4f7a1 from @somini and was discussed
at <#587>. As of now, one can
tag entries in the compose menu and use <group-alternatives> to group
those entries into one. If all the entries are tagged (including the
fundamental part), then the email become a multipart/alternative one,
otherwise it becomes a multipart/mixed one.

There is some weird things to be noted, though: when postponing a
multipart/alternative mail and then recall it, those entries get
split up. This does not occurred for multipart/mixed mails.

flatcap added a commit that referenced this issue May 2, 2018

Initial support for multipart/alternative
This is still WIP, mutt segfaults right after sending the email.

This is the work of @oblitum.

References #587

flatcap added a commit that referenced this issue May 2, 2018

support for multipart/alternative and multipart/mixed
This work is based on commit 5b4f7a1 from @somini and was discussed
at <#587>. As of now, one can
tag entries in the compose menu and use <group-alternatives> to group
those entries into one. If all the entries are tagged (including the
fundamental part), then the email become a multipart/alternative one,
otherwise it becomes a multipart/mixed one.

There is some weird things to be noted, though: when postponing a
multipart/alternative mail and then recall it, those entries get
split up. This does not occurred for multipart/mixed mails.
@flatcap

This comment has been minimized.

Member

flatcap commented May 3, 2018

Closed by 08f6862

@flatcap flatcap closed this May 3, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment