emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orgmode] using orgmode to send html mail?


From: David Maus
Subject: Re: [Orgmode] using orgmode to send html mail?
Date: Wed, 31 Mar 2010 22:37:19 +0200
User-agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (Gojō) APEL/10.7 Emacs/24.0.50 (i486-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)

Eric Schulte wrote:
>Hi David,
> [...]
>>
>> 2nd/
>>
>> The usage of multipart/alternative is not in compliance with the
>> specs, too.  There it reads:
>>
>> [...]
>>
>> So if you attach *only a part* of the plain text message body, you
>> should not use multipart/alternative: Because
>>
>>   1. a part of a message is not "an 'alternative' version of the same
>>      information."
>>
>>   2. if recipients user agent prefers html messages it will display
>>      only the html'ized part.
>>

>I should have been clearer here.  I *am* using the multipart/alternative
>appropriately.  When a chunk of org-mode text is converted to html I am
>adding a single multipart/alternative block with two alternatives, both
>the plain org-mode text, and the html, so that users like me who prefer
>to see plain text can do so, and users of web clients like gmail can see
>nice markup.

Okay, should have looked closer to the code.

1/

But I still feel uncomfortable with the current solution: Even if the
message created by current org-mail-htmlize is a valid MIME message (I
think so) it is a rather complex MIME structure and I have no idea how
other MUAs will display such a message.

Moreover, this complexity is unecessary if we make the assumption:

  If substantial parts of your message require html markup do be
  displayed by a some of your recipients, than send a html
  representation of the entire message along with the plain text.[1]

For a recipient who preferes html the result is the same: For him the
substantial parts are displayed in a meaningful way.  People who
prefer or depend on plain text get the plain text.  And we avoid
uneccesary complexity.

Thinking functional this might be the first function of
org-mail-htmlize[1]: Create a html representation of message body if
necessary or appropriate.

2/

The second function: Attach external files that are referenced in the
message.  This might be useful even if you don't send out html
messages: All external files are stashed into a multipart/mixed
container along with a Content-Id: header field.

Than all references are changed accordingly to point to the attached
files:

  - for html use src/href with the cid: prefix

  - for text: good question.  Maybe replace occurences of the file
    with a customizable string saying: "see attached file foo.bar".

3/

For Wanderlust multipart/alternative is (replace "_" by "-")

__<<alternative>>_{

and closing

__}_<<alternative>>

4/

Detecting the plain text body should not just stop on end of buffer
but also on the first occurence of a MIME delimiter: Maybe the user
already added a attachment.

And, last not least: This has the potential for going into contrib.
Maybe it should be renamed to org-mime -- it's neither just about
mail, nor just about htmlizing.

HTH
  -- David

[1] This assumption may also address the concerns about sending html
messages: From my perspective html message are not a problem in
itself.  Sometimes people have to send html messages (organizational
rules) and sometimes it is appropriate for content to render properly.
As far as I read on the topic of html message they got their bad name
because people where sending html messages implicitely assuming that
all recipients /can/ read them in the same "fancy" format as they did.
Such an assumtion is wrong because it does not take into account that
information and it's representation are two different things and
computers are create in processing and (re)formatting information.

Anyway, what org-mail-htmlize really misses is a function that adds
fance pictures (cats!), sounds and maybe even flash animations to the
messages :D



--
OpenPGP... 0x99ADB83B5A4478E6
Jabber.... address@hidden
Email..... address@hidden

Attachment: pgpiHeVa1VpoR.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]