Mailspring: [Feature request] Sending in plaintext only

[rossmeissl]

Over at Nylas Mail they made clear they did not intend to support sending in plaintext only. We already have one related request here, but I wanted to give it its own issue.

Is this something Mailspring intends to support?

Does this feature exist in another mail client or tool you use?

Yes, Thunderbird.

[pierrebeaucamp]

This missing feature was a big annoyance with Nylas. Many productivity tools, like Github, Pivotal Tracker or some Helpdesk let you answer to threads over email.

This works well with plaintext email - i.e signatures and previous responses are stripped from the email body. However this always failed when sending HTML Emails from Nylas, which resulted in me spamming various threads and mailing lists.

I would love to see a plaintext only option for composing emails

[ghost]

yeah i'm really into this. down with the HTML smog-beast.

[rossmeissl]

@taohansen please +1 the original post!

[mclang]

Plain text is needed.
I will check mailspring again when sending plain text is supported. And it would be __splendid__ if there would be settings to prefer plain text also when opening incoming mail!

[repat]

I just uninstalled Mailspring again because of this. I just assumed it's a standard feature. Loved the rest though. As soon as it's added, I'll switch from Thunderbird! :)

[rkitover]

Please, please add this, for linux users it's kind of essential. The mailing lists I'm using now outright reject HTML email.

[Arteneko]

Another ask, I write most, if not all, my emails in plaintext, including signatures.

Sadly, that's the only feature that refrains me from using it.

[perhurt]

I'd switch to Mailspring in a heartbeat if plaintext was supported. Plaintext is essential for "professional emailers" as it's required by many mailinglists/productivity tools.

[lloydhazlett]

I would also love to see plaintext composition supported and configurable as the default. Wouldn't miss signature support if it was left out for plaintext initially.

[doprdele]

please plaintext

[Arteneko]

I've decided to try to use Mailspring for some time and I've been forced to stop using it, for the following reasons:

• No plaintext support
• No "unified inbox"
• New email polling only polls for Inboxes, and I haven't found any way to select another folders to poll. I need it because I have a lot of sort rules applied on my emails.
• Finally, and the most annoying, I sign with the following signature:

Regards,
- A

and every time I tried that, when putting a space after the -, it transformed it into a bullet list.

[mclang]

That - mclang -> bullet list thing is making me crazy also!

Is there anywhere reason why making plain text seems to be such a long haul?

[athei]

Yes this client is essentially useless without plaintext support for everything that is mailing list related. Can we have a status update?

[Arteneko]

Indeed, I think that we should get a status update, since the issue was opened more than one year ago, and we still haven't received any kind of feedback.

[rudolphpienaar]

Two features are keeping mailsrpring from being my everyday client (and preventing me from a pro subscription):

1. Lack of fixed width font for plaintext email display and sending
2. Lack of calendar integration

[ljmamoreira]

I really need plaintext email.

[Arteneko]

Looks like they don't care, better to make a fork and build a plaintext-compatible mailspring fork.

[mclang]

They haven't said this will NOT be implemented... I really hope it will so that I can start using Mailspring again fully.

[chipbuster]

Based on #1222 and #1273, it looks like plain text is definitely at least on the map. Personally, I can't wait--Thunderbird is passable, but I look at my Windows and MacOS systems and can't help but feel a pang of jealousy...

[rkitover]

So I use an email client called Geary now, it's beautiful and modern and works perfectly with gmail, supports plaintext and markdown. Also it's not electron.

[StevenMapes]

Having switched to Mailspring from Thunderbird I vastly prefer it but this is a required feature for me as I have clients who have platforms that require plain-text emails to be parsed so I need to ensure I can easily create emails in the format that require for user testing

[walhallaRV]

Hi,
I gave Mailspring a try (use Thunderbird) and was pretty surprised. Lot's of good things - GRATS! But without writing / reading incoming/outgoing emails it is impossible to use for me!

And without a proper signature ("-- ") it is unusable too. So give us please the option to disable all this HTML-stuff und use emails as we want / need.

Registering and transfering data to the cloud should really be an option too! So, i will uninstall, keep on using TB and will return if / when this simple thing is working.

[tpluscode]

I interact with old-school mailing lists which prefer plain-text emails. Please add this feature!

[Gizmo091]

This was the first option that i wanted configure in mailspring. But does not exists :s . So uninstall mailspring and go back to thunderbird :S

[RaitoBezarius]

What's up with this feature?
How can we help to make it possible? It's really useful.

[shreyasminocha]

Where should someone wishing to create a PR start?

[Kabouik]

I would like to be able to compose plain text emails as well. Regardless of mailing lists, I do not want to use complex formatting when not necessary, and I prefer to prioritize widespread compatibility. This is a key feature for me which might eventually decide whether Mailspring is my default client or not

[ponmy]

+1 for plain text emails please

[bengotow]

Hey folks! Happy to announce that preliminary support for plaintext messages will be in the next release! I've added an option to enable a plaintext composer in Preferences > General, and you can also compose an individual plaintext draft / reply by holding the option key.

There are a few caveats at this point, but I think this will be a big improvement for those of you that need plaintext support.

• Most composer features are removed when you're in plaintext mode including a few that we could support, including Templates and Signatures. The authoring interfaces for templates and signatures create rich HTML, so we'll need to introduce plaintext editing for these before we can add support in the composer.

• All attachments are appended to the end of the document. Some clients support authoring plaintext with embedded images via a multipart/mixed MIME output like <text part><file part><text part>, but it'd be a challenge to do in Mailspring and seems like an edge case.

• The plain text composer wraps to 72 characters fairly forcefully, which I think is a best practice. The line length is not currently configurable because I didn't see much evidence that folks alter it, but it could be in the future without much work.

• When an email arrives that contains ONLY a plaintext MIME part, Mailspring now displays it in the app in plain text with display:pre formatting so newlines are preserved. I think this will make the mailing list reading experience much better.

  • Potential future work: the app does not attempt to hide / ellipsis quoted text from plaintext messages right now, and long conversations can become very, very long to read since the conversation panel displays the messages as a thread. I'd be interested to hear how other plaintext clients tackle this, if at all, and very open to PRs implementing a plaintext version of this function: https://github.com/Foundry376/Mailspring/blob/master/app/internal_packages/message-list/lib/email-frame.tsx#L86:L86.

• I know that bottom-posting is supposed to be a plaintext email best practice, but I noticed Thunderbird defaults to top-posting and I copied that behavior. I personally think top posting is preferable for threaded mail clients (Mailspring, Gmail, etc.) which typically hide quoted text and display messages as a conversation.

This should ship in a release very soon, stay tuned!

[Arteneko]

To be honest, I kind of lost hope to see this feature being looked at.

Glad to see that it's now WIP for a close release!

[Schparky]

Seems this is released despite the "Open" status. Problem is, it defaults to plain-text. I had to toggle the "enable rich text" setting to get rich text mode back.

[StevenMapes]

This isn't working in the latest snap package. You can hold alt/options and the "Write a reply" changes to "Write a plain-text reply" but you cannot actually then click on the reply or compose as the alt/option key blocks the access.

Mailspring Version: 1.7.4-d54ff730
OS: Kubuntu 18.04
Plasma: 5.12.9

Update

You have to hold ctrl + alt in order for this to work on Kubuntu with Plasma

[tukusejssirs]

I have installed (updated) v1.7.4 from RPM package on CentOS 8. I have enabled the rich-text features toggle in the settings (actually I did not change it at all). Now (after Mailspring upgrade) all plain-text email are misformatted, i.e. the newlines are replaced by spaces (the whole email body is now only a single line).

I think that when a plain-text email is received (e.g. no HTML tags are in the body) and the rich-text toggle is enabled, the email should be output as is (i.e. like a plain-text email).

Update:

I think that we should be able to choose whether we want to compose rich-text or plain-text email in the composer itself too. Also in general, we might want to display a single email (or thread) in plain-text; i.e. the default setting should be overridable per email/thread. So there should be a plain/rich toggle in two places: one in the composer window and the other in the email/thread.

For example, I prefer to compose rich-text emails, but sometimes I need/want to send a single plain-text email.

Another example: someone sends me a plain-text email, so I should _by default_ reply with a plain-text email.

Another example: I send a rich-text email, but the other party replies me with a plain-text email, so that incoming email should be displayes as plain-text.

Update 2:

Another thing I have just noticed: the encoding.

I have received an email with the following in its header:

Content-type: text/plain; charset=windows-1250
~~Content-Transfer-Encoding: quoted-printable~~

Then, the email body is written in Slovak, therefore there are some letters with diacritics (like čšťíô).

The problem is that all of those letters are replaced by =XX, where X is a upper-case hex digit, for example:
- ú → =FA;
- í → =ED;
- ľ → =BE.

This was not a problem prior to v1.7.4.

Update 3:

Sorry for my Update 2–it was based on the email source, not on the output email body, therefore it is not an issue and never was.

[IjonFryderyk]

Alt shortcut interferes with alt+tab. When you want to switch between apps using alt+tab you also end up with plain text option activated. It would be great if this shortcut could be configurable or changed to another one that doesn't mess with alt+tab.

[budinero]

Alt shortcut interferes with alt+tab. When you want to switch between apps using alt+tab you also end up with plain text option activated. It would be great if this shortcut could be configurable or changed to another one that doesn't mess with alt+tab.

Hi, I also have this problem. In kde, alt+click key is reserved to move windows. I can start a paintext mail with ctrl+alt+click. Nevertheless, it would be interesting if this shortcut could be changed to Ctrl key. In addition, it would be great if a new paintext mail can be started with Alt+c or Ctrl+c.

[bengotow]

Hey folks! Thanks for all the replies here. It turns out there was a pretty nasty bug in the 1.7.4 release. I wrote a little state machine to keep track of whether the Alt key was down and enable the conditional "plaintext mode", but certain interactions (like holding Alt and tabbing out of the app on Linux) caused us not to receive the "alt key up" and the app could become stuck in plaintext mode!

I'm really sorry, that was a major oversight on my part - I mostly didn't notice because I use a Mac and there's very little use of the Alt key. This was fixed in the latest release 1.7.6.

Also thanks @StevenMapes for the note about Alt blocking your clicks, I had no idea that was a thing! Will need to investigate and see if we can fix that somehow.

@tukusejssirs, I think once the Alt-key option is working correctly, you should be able to choose whether to reply with rich text or plain text by holding the Alt key. It sounds like you're also seeing that when you're in rich text mode, plain text emails are displayed as one long line. I have seen a few other reports of that and I'm still trying to find a test case. As of 1.7.4, if Mailspring receives an email which has ONLY a plaintext version, it displays that. Otherwise, it should display the rich text version as rich text.

If anyone else has an example of the "one long line" rendering bug, I'd love to see the raw MIME of the message. You can view + copy/paste it out of Mailspring by clicking the white space next to the Reply button and choosing "View Original" from the hidden dropdown that appears. (Real option for this coming soon—we need to refactor the conversation view a bit so that a message can be "selected", and then options like this can go in the menu!)

Thanks everyone for your help and patience!

[chipbuster]

@bengotow If I can find one that I can share, would you prefer it on this issue or should I open a new one for it?

EDIT: I just remembered there's an existing issue already.

[danger89]

Ok.. I think I move away from Mailspring, because of this.