On 2017-04-28, Darac Marjal <mailingl...@darac.org.uk> wrote:
> On Thu, Apr 27, 2017 at 03:46:14PM -0400, Patrick Shanahan wrote:
>>
>>*attaching* it *is* the way "_winthin_ _mutt_".
>>
>>mutt is a *text* application, not markup/markdown/html/css/.... the way
>>you define text on *your* system is what you get, not what is sent or what
>>you send.
>
> Actually, mutt DOES have some support for more than text/plain. If a
> message is in text/enriched type, mutt knows how to render that to the
> terminal. I can see that a sufficiently motivated developer could add,
> say, a markdown parser there just as easily (or if markdown is too
> vague, something as safely-defined as text/enriched).
I don't have an need for rendering messages that isn't already taken
care of by the mailcap support.
> To me, the larger hurdle is writing messages in a markup language.
Exactly.
> Is there any method in mutt to cope with the fact that $EDITOR has
> just passed it something other than text/plain (that is, some method
> OTHER than ^T on the compose screen)?
One option that would be nice would simply be the ability the convert
a plaintext body into multipart-alternative containing the plaintext
version and an HTML version comprising nothing but the plaintext
message between <xmp> </xmp> tags.
Another nice option would be support for running the text/plain body
through markdown/RST/asciidoc in order to produce the html
alternative.
Unfortunately, other MUA's support for simple text/plain is getting
worse and worse.
--
Grant Edwards grant.b.edwards Yow! Hello, GORRY-O!!
at I'm a GENIUS from HARVARD!!
gmail.com
