David Maus <dm...@ictsoc.de> writes:
[...]
> 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.
>
Yes, but since it is valid MIME I'm personally very happy with it. Also
both Gmail and Gnus both play well with these complex embedded multipart
structures. Unless it actually becomes a problem I don't see any reason
not to use the standard to it's full power.
>
> 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]
>
I don't agree with that assumption :)
I often want only a table, list, or latex-heavy section of my email to
be converted to html. I find that other parts of the email
(e.g. previous emails in the thread nested behind ">" characters,
signatures, etc...) work better when sent as pure text.
>
> 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.
>
Oh, so this would be a slightly different issue,
So this function could be run *every* time an email is sent. I agree
that in those cases running on the entire message would be the right way
to go. Currently if `org-mail-htmlize' is called with no active region
then this is what happens. So I believe the code as currently written
should satisfy the above points, resulting in a simple structure (only
one multipart/alternative section) which contains the entire email and
would be appropriate for running on every mail sent.
>
> 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".
>
I'm not sure I understand, I'm currently happy with my mail agent's
method of attaching files to email, what else would this use of the
function add aside from a new attachment syntax.
>
> 3/
>
> For Wanderlust multipart/alternative is (replace "_" by "-")
>
Thanks, I've applied this to the `org-mail-multipart' function in the
code repository. I'm not entirely sure if I got the full multipart
syntax correct, but if I did then hopefully this means that WL is now
supported.
>
> __<<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.
>
Good point, one open question here is how to treat that mime border, I'm
thinking it may be best to simply stash it in a
#+BEGIN_HTML
original mime content
#+END_HTML
block, so that it survives the Org-mode export unscathed, however maybe
it's simpler just to end the html alternative part at the first mime
border.
Either way this will require a mailer specific function to search for
the next multipart section.
>
> 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.
>
Fair point. I've just renamed the functions and the repository, and it
is now available at [1]. If there's a better place to host this to
encourage collaboration please let me know.
Thanks -- Eric
>
> 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
>
:) agreed, blink tags around every noun
>
>
>
> --
> OpenPGP... 0x99ADB83B5A4478E6
> Jabber.... dmj...@jabber.org
> Email..... dm...@ictsoc.de
Footnotes:
[1] http://github.com/eschulte/org-mime
_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
