Re: [Orgmode] using orgmode to send html mail?
David Maus writes: > Eric Schulte wrote: >>David Maus writes: > >>> Eric Schulte wrote: > > 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. >>> >>> Right, this would be nice for people who are obliged to send out html >>> messages. If this is turned on org-mime should display the string >>> "HTML" in the mode line. In the WL it's done this way: >>> >>> , >>> | (defun dmj/wl-send-html-message-draft-init () >>> | "Create buffer local settings for maybe sending html message." >>> | (unless (boundp 'dmj/wl-send-html-message-toggled-p) >>> | (setq dmj/wl-send-html-message-toggled-p nil)) >>> | (make-variable-buffer-local 'dmj/wl-send-html-message-toggled-p) >>> | (add-to-list 'global-mode-string >>> |'(:eval (if (eq major-mode 'wl-draft-mode) >>> |dmj/wl-send-html-message-toggled-p >>> ` >>> >>> This function is hooked into mime-edit mode and set's a buffer local >>> variable that indicates "html message mode" and is displayed in the >>> mode line. >>> > >>Another option here is to add a defadvice to the actual sending command >>(C-c C-c in gnus) such that if the command is called with a prefix >>argument, then `org-mime-htmlize' is run on the entire message before >>mail delivery. To me this seems like a simpler solution than the above. > > Yes, somehow we have to hook or defadvice before mml/semi translates > the message buffer to real MIME. I'm not sure about the defadive: We > would change functioallity of the translating function globally. > I've done this previously. Luckily orgstruct-mode already intercepts C-c C-c (which is used to send mail in gnus) and it is not difficult to check for a prefix argument at that stage (before any mime encoding) and optionally run an html conversion there. > >>> >>> What I meant was: Suppose you write a document in Org with references >>> to external files (images etc.). If finished you'd like this document >>> to a fellow by mail including all external files. So this function >>> collects all these files, and maybe converts the message body to html, >>> fires up Gnus/WL with a new message and inserts something like >>> >>> < #multipart type="alternate"> >>> < #part type="text/plain"> ...plain text body... >>> < #part type="text/html"> ...html body... >>> < #/multipart> >>> < #multipart type="mixed"> >>> < #part type="image/png"> image1.png >>> < #part type="image/png"> image2.png >>> ... >>> < #/multipart> >>> >>> That is: The original document including all external files -- and all >>> references in the original file are replaced by references to the >>> attachments. >>> > >>If I'm understanding correctly both you and Dan seem to be in favor >>of exporting to mime and packaging up the raw mime information from >>the org-mode buffer. I'm leaning towards thinking that it may be >>easier to simply bring the mail buffer to the org-mode file by saving >>it to a temporary location alongside the org-mode file (so all links >>resolve). It will probably take some experimentation to find out >>which approach is more feasible/natural. > > Funny thing: It's basically the same operation, only difference is in > the original content's source: > > ++ > | Org buffer |--+ > ++ |++ ++ > +--->| MIME setup |-->| Message buffer | > ++ |++ ++ > | Message buffer |--+ > ++ > Yup, I looks like it will just be a question of how to position the resulting message buffer so that all of the references resolve. Thanks -- Eric > > -- David > > -- > OpenPGP... 0x99ADB83B5A4478E6 > Jabber dmj...@jabber.org > Email. dm...@ictsoc.de ___ 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
Re: [Orgmode] using orgmode to send html mail?
Eric Schulte wrote: >David Maus writes: >> Eric Schulte wrote: 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. >> >> Right, this would be nice for people who are obliged to send out html >> messages. If this is turned on org-mime should display the string >> "HTML" in the mode line. In the WL it's done this way: >> >> , >> | (defun dmj/wl-send-html-message-draft-init () >> | "Create buffer local settings for maybe sending html message." >> | (unless (boundp 'dmj/wl-send-html-message-toggled-p) >> | (setq dmj/wl-send-html-message-toggled-p nil)) >> | (make-variable-buffer-local 'dmj/wl-send-html-message-toggled-p) >> | (add-to-list 'global-mode-string >> |'(:eval (if (eq major-mode 'wl-draft-mode) >> |dmj/wl-send-html-message-toggled-p >> ` >> >> This function is hooked into mime-edit mode and set's a buffer local >> variable that indicates "html message mode" and is displayed in the >> mode line. >> >Another option here is to add a defadvice to the actual sending command >(C-c C-c in gnus) such that if the command is called with a prefix >argument, then `org-mime-htmlize' is run on the entire message before >mail delivery. To me this seems like a simpler solution than the above. Yes, somehow we have to hook or defadvice before mml/semi translates the message buffer to real MIME. I'm not sure about the defadive: We would change functioallity of the translating function globally. >> >> What I meant was: Suppose you write a document in Org with references >> to external files (images etc.). If finished you'd like this document >> to a fellow by mail including all external files. So this function >> collects all these files, and maybe converts the message body to html, >> fires up Gnus/WL with a new message and inserts something like >> >> < #multipart type="alternate"> >> < #part type="text/plain"> ...plain text body... >> < #part type="text/html"> ...html body... >> < #/multipart> >> < #multipart type="mixed"> >> < #part type="image/png"> image1.png >> < #part type="image/png"> image2.png >> ... >> < #/multipart> >> >> That is: The original document including all external files -- and all >> references in the original file are replaced by references to the >> attachments. >> >If I'm understanding correctly both you and Dan seem to be in favor >of exporting to mime and packaging up the raw mime information from >the org-mode buffer. I'm leaning towards thinking that it may be >easier to simply bring the mail buffer to the org-mode file by saving >it to a temporary location alongside the org-mode file (so all links >resolve). It will probably take some experimentation to find out >which approach is more feasible/natural. Funny thing: It's basically the same operation, only difference is in the original content's source: ++ | Org buffer |--+ ++ |++ ++ +--->| MIME setup |-->| Message buffer | ++ |++ ++ | Message buffer |--+ ++ -- David -- OpenPGP... 0x99ADB83B5A4478E6 Jabber dmj...@jabber.org Email. dm...@ictsoc.de pgpBYHUgVtu2w.pgp Description: PGP signature ___ 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
Re: [Orgmode] using orgmode to send html mail?
David Maus writes: > Eric Schulte wrote: >>> >>> 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. > > Right, this would be nice for people who are obliged to send out html > messages. If this is turned on org-mime should display the string > "HTML" in the mode line. In the WL it's done this way: > > , > | (defun dmj/wl-send-html-message-draft-init () > | "Create buffer local settings for maybe sending html message." > | (unless (boundp 'dmj/wl-send-html-message-toggled-p) > | (setq dmj/wl-send-html-message-toggled-p nil)) > | (make-variable-buffer-local 'dmj/wl-send-html-message-toggled-p) > | (add-to-list 'global-mode-string > |'(:eval (if (eq major-mode 'wl-draft-mode) > |dmj/wl-send-html-message-toggled-p > ` > > This function is hooked into mime-edit mode and set's a buffer local > variable that indicates "html message mode" and is displayed in the > mode line. > Another option here is to add a defadvice to the actual sending command (C-c C-c in gnus) such that if the command is called with a prefix argument, then `org-mime-htmlize' is run on the entire message before mail delivery. To me this seems like a simpler solution than the above. > >>> >>> 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. > > What I meant was: Suppose you write a document in Org with references > to external files (images etc.). If finished you'd like this document > to a fellow by mail including all external files. So this function > collects all these files, and maybe converts the message body to html, > fires up Gnus/WL with a new message and inserts something like > > < #multipart type="alternate"> > < #part type="text/plain"> ...plain text body... > < #part type="text/html"> ...html body... > < #/multipart> > < #multipart type="mixed"> > < #part type="image/png"> image1.png > < #part type="image/png"> image2.png > ... > < #/multipart> > > That is: The original document including all external files -- and all > references in the original file are replaced by references to the > attachments. > Ah, this sounds similar to the extension proposed by Dan and seconded by a couple of others on the list. It seems like the big question here is how to convey all of the required mime information from the org-mode buffer to the message body. If I'm understanding correctly both you and Dan seem to be in favor of exporting to mime and packaging up the raw mime information from the org-mode buffer. I'm leaning towards thinking that it may be easier to simply bring the mail buffer to the org-mode file by saving it to a temporary location alongside the org-mode file (so all links resolve). It will probably take some experimentation to find out which approach is more feasible/natural. > > Original > , > | ... > | As you can see in [[file:figure1.png][Figure 1]], cats > | *are* the cutest animals on earth. > | ... > ` > > "figure1.png" will be attached and the reference adjusted to the > attachment. > > HTML > , > | As you can see in Figure > 1, > | cats are the cutest animals on earth. > ` > > Plain > > , > | As you can see in Figure 1 (see attached file: figure1.png), cats > | *are* the cutest animals on earth. > ` > >>> 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. > > Yes, it is simpler. Simply search for the end of the message body > with the condition: either eobp or MIME delimiter. > > For example when in mml (line 92ff in org-mime.el): > > ,
Re: [Orgmode] using orgmode to send html mail?
Eric Schulte wrote:
>>
>> 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.
Right, this would be nice for people who are obliged to send out html
messages. If this is turned on org-mime should display the string
"HTML" in the mode line. In the WL it's done this way:
,
| (defun dmj/wl-send-html-message-draft-init ()
| "Create buffer local settings for maybe sending html message."
| (unless (boundp 'dmj/wl-send-html-message-toggled-p)
| (setq dmj/wl-send-html-message-toggled-p nil))
| (make-variable-buffer-local 'dmj/wl-send-html-message-toggled-p)
| (add-to-list 'global-mode-string
|'(:eval (if (eq major-mode 'wl-draft-mode)
|dmj/wl-send-html-message-toggled-p
`
This function is hooked into mime-edit mode and set's a buffer local
variable that indicates "html message mode" and is displayed in the
mode line.
>>
>> 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.
What I meant was: Suppose you write a document in Org with references
to external files (images etc.). If finished you'd like this document
to a fellow by mail including all external files. So this function
collects all these files, and maybe converts the message body to html,
fires up Gnus/WL with a new message and inserts something like
< #multipart type="alternate">
< #part type="text/plain"> ...plain text body...
< #part type="text/html"> ...html body...
< #/multipart>
< #multipart type="mixed">
< #part type="image/png"> image1.png
< #part type="image/png"> image2.png
...
< #/multipart>
That is: The original document including all external files -- and all
references in the original file are replaced by references to the
attachments.
Original
,
| ...
| As you can see in [[file:figure1.png][Figure 1]], cats
| *are* the cutest animals on earth.
| ...
`
"figure1.png" will be attached and the reference adjusted to the
attachment.
HTML
,
| As you can see in Figure
1,
| cats are the cutest animals on earth.
`
Plain
,
| As you can see in Figure 1 (see attached file: figure1.png), cats
| *are* the cutest animals on earth.
`
>> 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.
Yes, it is simpler. Simply search for the end of the message body
with the condition: either eobp or MIME delimiter.
For example when in mml (line 92ff in org-mime.el):
,
| (html-end (or (and region-p (region-end))
| (if (not (re-search-forward "^<#part\\|^<#multipart" nil t))
| (point-max)
| ;; one line up
| (end-of-line 0)
| (point
`
With this you can even catch the signature that is separate by "--
\n". If re-search-forward finds an attachment the body ends right
before. Small glitch: This code assumes MIME delimiters start at the
beginning of a line ("^").
-- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de
pgpHXDu19724y.pgp
Description: PGP signature
___
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
Re: [Orgmode] using orgmode to send html mail?
David Maus 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.
>
> __<>_{
>
> and closing
>
> __}_<>
>
> 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, blin
Re: [Orgmode] using orgmode to send html mail?
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 "-")
__<>_{
and closing
__}_<>
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 dmj...@jabber.org
Email. dm...@ictsoc.de
pgpx9y8vxiXzn.pgp
Description: PGP signature
___
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
Re: [Orgmode] using orgmode to send html mail?
Hi David, David Maus writes: [...] > Two remarks: > > 1st/ > > , > | (add-to-list 'html-images > | (org-mail-file (concat "image/" ext) path id)) > ` > > Using the file extension as subtype is not in compliance with the > specs. For instance the MIME type of "filename.jpg" is image/jpeg, > not image/jpg (cf. RFC 2046, 4.2). > > What you need is kind of a function or software that returns MIME type > of a file name. In SEMI it's `mime-find-file-type'. Or maybe don't > set the type, maybe mml will pick a type for you. > Ah thanks, I will look to see if there is such a function distributed with the core Emacs, else a simple alist should suffice. > > 2nd/ > > The usage of multipart/alternative is not in compliance with the > specs, too. There it reads: > > RFC2046, 5.1.4 > > , > | 5.1.4. Alternative Subtype > | > | The "multipart/alternative" type is syntactically identical to > | "multipart/mixed", but the semantics are different. In particular, > | each of the body parts is an "alternative" version of the same > | information. > | > | Systems should recognize that the content of the various parts are > | interchangeable. Systems should choose the "best" type based on the > | local environment and references, in some cases even through user > | interaction. As with "multipart/mixed", the order of body parts is > | significant. In this case, the alternatives appear in an order of > | increasing faithfulness to the original content. In general, the best > | choice is the LAST part of a type supported by the recipient system's > | local environment. > | > | In general, user agents that compose "multipart/alternative" entities > | must place the body parts in increasing order of preference, that is, > | with the preferred format last. For fancy text, the sending user agent > | should put the plainest format first and the richest format > | last. Receiving user agents should pick and display the last format > | they are capable of displaying. In the case where one of the > | alternatives is itself of type "multipart" and contains unrecognized > | sub-parts, the user agent may choose either to show that alternative, > | an earlier alternative, or both. > ` > > 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. > > Better use multipart/alternative for plain text and html of the entire > body and additional multipart/mixed for snippets. If the html output > should contain images, than maybe use a multipart/mixed with type > text/html beneath the text/plain, so the receiving MUA might pick it > up when prefering html. > > With regards to SEMI the delimiters are (inserted a space between two > succeeding dashes): > > - single entity: And the limits of user email to discuss email have been reached :) gnus seems to have mangled some of the following examples, but I have tried to flesh out the 'semi portions org-mail-htmlize given what I was able to salvage (see the latest commit). I still can't figure out the SEMI multipart/alternative syntax. Please let me know if you have the syntax at hand, feel like submitting a patch, or you would like commit permission to the git repo. Much Thanks! -- Eric ___ 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
Re: [Orgmode] using orgmode to send html mail?
Eric Schulte wrote:
>So I believe inline LaTeX images are working in gnus, see here
>[cid]and immediately below
>[cid]
>This turned out to be fairly easy, and didn't require any encoding or
>explicit mime function calls.
>I've also re-structured the code so that it should be easy to apply the
>appropriate mime markup for WL and VM. There are now two mime-library
>dependent functions `org-mail-file' and `org-mail-multipart' each of
>which contains a `case' block for library-specific behavior, e.g.
>(case org-mail-mime-library
> ('mml (format (concat "<#multipart type=alternative><#part type=text/plain>"
>"%s<#part type=text/html>%s<#/multipart>\n")
>plain html))
> ('semi "?")
> ('vm "?"))
>everything is available at http://github.com/eschulte/org-html-mail
>I'd love to hear feedback, suggestions, or expansion of the missing WL
>and VM portions of the two functions mentioned above.
Two remarks:
1st/
,
| (add-to-list 'html-images
| (org-mail-file (concat "image/" ext) path id))
`
Using the file extension as subtype is not in compliance with the
specs. For instance the MIME type of "filename.jpg" is image/jpeg,
not image/jpg (cf. RFC 2046, 4.2).
What you need is kind of a function or software that returns MIME type
of a file name. In SEMI it's `mime-find-file-type'. Or maybe don't
set the type, maybe mml will pick a type for you.
2nd/
The usage of multipart/alternative is not in compliance with the
specs, too. There it reads:
RFC2046, 5.1.4
,
| 5.1.4. Alternative Subtype
|
| The "multipart/alternative" type is syntactically identical to
| "multipart/mixed", but the semantics are different. In particular,
| each of the body parts is an "alternative" version of the same
| information.
|
| Systems should recognize that the content of the various parts are
| interchangeable. Systems should choose the "best" type based on the
| local environment and references, in some cases even through user
| interaction. As with "multipart/mixed", the order of body parts is
| significant. In this case, the alternatives appear in an order of
| increasing faithfulness to the original content. In general, the best
| choice is the LAST part of a type supported by the recipient system's
| local environment.
|
| In general, user agents that compose "multipart/alternative" entities
| must place the body parts in increasing order of preference, that is,
| with the preferred format last. For fancy text, the sending user agent
| should put the plainest format first and the richest format
| last. Receiving user agents should pick and display the last format
| they are capable of displaying. In the case where one of the
| alternatives is itself of type "multipart" and contains unrecognized
| sub-parts, the user agent may choose either to show that alternative,
| an earlier alternative, or both.
`
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.
Better use multipart/alternative for plain text and html of the entire
body and additional multipart/mixed for snippets. If the html output
should contain images, than maybe use a multipart/mixed with type
text/html beneath the text/plain, so the receiving MUA might pick it
up when prefering html.
With regards to SEMI the delimiters are (inserted a space between two
succeeding dashes):
- single entity:
bindPnueGQg2l.bin
Description: type/subtype
pgpm5GWk8eiO7.pgp
Description: PGP signature
___
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
Re: [Orgmode] using orgmode to send html mail?
Hi,
plain html))
('semi "?")
('vm "?"))
#+end_src
everything is available at http://github.com/eschulte/org-html-mail
I'd love to hear feedback, suggestions, or expansion of the missing WL
and VM portions of the two functions mentioned above.
<><>
David Maus writes:
> Okay, took a look on the specs and attached is a memo on how an
> implementation of org to MIME could be done. The MIME delimiters of
> SEMI and mml are quite similar so there's already a generic function
> that creates representation of a MIME message for both.
>
> I've published this memo on Worg, too, occupying some space in
>
> http://orgmode.org/worg/org-devel.php
>
I took a look at this page, but it wasn't entirely clear to me what the
SEMI markup language should look like. As mentioned above, for now I've
gone with `case' statements for each mime library, rather than an alist
of format strings -- in the off chance that different libraries could
require information in a different order.
>
> The tasks at hand would be: find the functions that attach a file in
> mime-edit-mode and mml-mode and look who they can be utilized.
>
I think that the mime markup libraries should handle attaching image
(including any encoding issues). For example in gnus with mml only the
path to the image need be supplied.
>
> Best
> -- David
>
Cheers -- Eric
>
> --
> OpenPGP... 0x99ADB83B5A4478E6
> Jabber dmj...@jabber.org
> Email. dm...@ictsoc.de
>
>
> Author: David Maus
> Date: 2010-03-25 21:56:50 CET
>
>
> Table of Contents
> =
> 1 Representing a MIME internet message
> 2 MIME delimiters of SEMI and mml
> 3 Generic function
> 4 Open questions
> 4.1 How to handle charset information?
> 4.2 How to attach files?
> 5 Quotes from the specs
> 5.1 MIME multipart: Notion of structured, related body parts
> 5.2 MIME multipart: order of entities inside a multipart
>
>
> 1 Representing a MIME internet message
> ~~~
>
>A MIME internet message consists of one or more MIME entities. Each
>MIME entity is of a distinct type and subtype, has a body and
>optional MIME headers related to it's content.
>
>A MIME entity is represented as a list:
>
>(TYPE SUBTYPE BODY CONT-HEAD)
>
>TYPE: Symbol of MIME media type (e.g. text, video, audio).
>
>SUBTYPE: Symbol of MIME media subtype (e.g. plain, html).
>
>BODY: String with entity body -or- list of other MIME entities.
>
>CONT-HEAD: List of cons with content related MIME header
> fields. The name of the header field without the
> prefix "Content-" is car, the value cdr.
>
>Example:
>
>
> '(text html "Headline" ((disposition . inline)))
>
>For messages of type multipart the body consists of a list of one
>or more MIME entities.
>
> '(multipart alternative
> '((text plain "* Headline")
> (text html "headline")))
>
> 2 MIME delimiters of SEMI and mml
> ~~
>
>The MIME delimiters are defined in an association list with a
>symbol of the library's name as key and delimiter format strings as
>values. For each library there are three formatstrings.
>
>(SYMBOL DELIM-SINGLE DELIM-SINGLE-CONT DELIM-MULTI)
>
>DELIM-SINGLE: Denoting a single MIME entity.
>
> Strings are passed in this order:
>
> 1. type
>
> 2. subtype
>
> 3. content header
>
> 4. body
>
>DELIM-SINGLE-CONT: Format of content header strings.
>
> Strings are passed in this order:
>
> 1. header field name
>
> 2. header field value
>
>DELIM-MULTI: Enclosing parts of a multipart entity.
>
> Strings are passed in this order:
>
> 1. subtype
>
> 2. body
>
> 3. subtype
>
>
> (setq org-mail-htmlize-mime-delimiter-alist
> '((semi "\n- -[%s/%s%s]\n%s" "\ncontent-%s: %s" "\n- -<<%s>>-{\n%s\n-
> -}-<<%s>>")
> (mml "\n<#part type=\"%s/%s\"%s>\n%s" " %s=\"%s\"" "\n<#multipart
> type=\"%s\">\n%s\n<#/multipart>")))
>
> 3 Generic function
> ~~~
>
>This generic function returns a string representation with MIME
>delimiters depending on the variable =org-mail-htmlize-mime-lib=.
>
>
> (setq org-mail-htmlize-mime-lib 'semi)
>
>
> (defun org-mail-htmlize-mime-entity (type subtype body
> &optional cont-head)
> "Return string representation of MIME entity.
>
> TYPE is the type of entity body.
> SUBTYPE is the subtype of body.
> BODY is the body of the entity. Either a string with the body
> content or a list with one ore more MIME entities.
> Optional argument CONT-HEAD is a list of cons with content
> specific headers, name in car and value in cdr."
> (let ((delimlst (assoc org-mail-htmlize-mime-l
Re: [Orgmode] using orgmode to send html mail?
Okay, took a look on the specs and attached is a memo on how an
implementation of org to MIME could be done. The MIME delimiters of
SEMI and mml are quite similar so there's already a generic function
that creates representation of a MIME message for both.
I've published this memo on Worg, too, occupying some space in
http://orgmode.org/worg/org-devel.php
The tasks at hand would be: find the functions that attach a file in
mime-edit-mode and mml-mode and look who they can be utilized.
Best
-- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber dmj...@jabber.org
Email. dm...@ictsoc.de
Author: David Maus
Date: 2010-03-25 21:56:50 CET
Table of Contents
=
1 Representing a MIME internet message
2 MIME delimiters of SEMI and mml
3 Generic function
4 Open questions
4.1 How to handle charset information?
4.2 How to attach files?
5 Quotes from the specs
5.1 MIME multipart: Notion of structured, related body parts
5.2 MIME multipart: order of entities inside a multipart
1 Representing a MIME internet message
~~~
A MIME internet message consists of one or more MIME entities. Each
MIME entity is of a distinct type and subtype, has a body and
optional MIME headers related to it's content.
A MIME entity is represented as a list:
(TYPE SUBTYPE BODY CONT-HEAD)
TYPE: Symbol of MIME media type (e.g. text, video, audio).
SUBTYPE: Symbol of MIME media subtype (e.g. plain, html).
BODY: String with entity body -or- list of other MIME entities.
CONT-HEAD: List of cons with content related MIME header
fields. The name of the header field without the
prefix "Content-" is car, the value cdr.
Example:
'(text html "Headline" ((disposition . inline)))
For messages of type multipart the body consists of a list of one
or more MIME entities.
'(multipart alternative
'((text plain "* Headline")
(text html "headline")))
2 MIME delimiters of SEMI and mml
~~
The MIME delimiters are defined in an association list with a
symbol of the library's name as key and delimiter format strings as
values. For each library there are three formatstrings.
(SYMBOL DELIM-SINGLE DELIM-SINGLE-CONT DELIM-MULTI)
DELIM-SINGLE: Denoting a single MIME entity.
Strings are passed in this order:
1. type
2. subtype
3. content header
4. body
DELIM-SINGLE-CONT: Format of content header strings.
Strings are passed in this order:
1. header field name
2. header field value
DELIM-MULTI: Enclosing parts of a multipart entity.
Strings are passed in this order:
1. subtype
2. body
3. subtype
(setq org-mail-htmlize-mime-delimiter-alist
'((semi "\n- -[%s/%s%s]\n%s" "\ncontent-%s: %s" "\n- -<<%s>>-{\n%s\n-
-}-<<%s>>")
(mml "\n<#part type=\"%s/%s\"%s>\n%s" " %s=\"%s\"" "\n<#multipart
type=\"%s\">\n%s\n<#/multipart>")))
3 Generic function
~~~
This generic function returns a string representation with MIME
delimiters depending on the variable =org-mail-htmlize-mime-lib=.
(setq org-mail-htmlize-mime-lib 'semi)
(defun org-mail-htmlize-mime-entity (type subtype body
&optional cont-head)
"Return string representation of MIME entity.
TYPE is the type of entity body.
SUBTYPE is the subtype of body.
BODY is the body of the entity. Either a string with the body
content or a list with one ore more MIME entities.
Optional argument CONT-HEAD is a list of cons with content
specific headers, name in car and value in cdr."
(let ((delimlst (assoc org-mail-htmlize-mime-lib
org-mail-htmlize-mime-delimiter-alist)))
(if (eq type 'multipart)
(format (nth 3 delimlst) subtype
(mapconcat '(lambda (b)
(apply 'org-mail-htmlize-mime-entity
(car b) (cadr b) (cddr b)))
body "")
subtype)
(format (nth 1 delimlst)
type subtype
(mapconcat '(lambda (h)
(format (nth 2 delimlst) (car h) (cdr h)))
cont-head "")
body
4 Open questions
~
4.1 How to handle charset information?
===
4.2 How to attach files?
=
The generic function expects BODY either be a string or a list.
Attaching binary file (image, etc.) requires to encode it so the
message will pass the message system. So we /might/ use kind of a
encoder (e.g. base64) on our own.
Or, wha
Re: [Orgmode] using orgmode to send html mail?
David Maus writes: > Eric Schulte wrote: >>Thanks Dan, > >>I'm happy to hear I'm not the only person who's enjoying playing with >>this :). > >>Aside from changing the mime-delimeters for VM and wanderlust, it seems >>to me that the only remaining step between the current functionality and >>a seamless use of org-mode for email composition, is the resolution of >>images as email attachments. That would allow emails with embedded >>latex (which I personally would find very compelling), as well as >>embedded ditaa diagrams and images. If anyone knows more about mime, >>I'd be interested to hear suggestions, but I may try a first pass using >>`replace-regexp' to replace all links with inline mime image >>attachments. > > Taking a look into the MIME specs (RFC2045ff) regarding this issue is > on my list. My biggest concern with utilizing more MIME capabilities > is, that you have little control over what the recipient's MUA will do. > good point, for example as I recall gmail insists on displaying all images at the bottom of an email message regardless of the placement of their mime spec. I wonder if it's possible for an html image link to reference an attachment? > > Don't know about VM, but with regards to WL I'd imagine something > like: > > - first represent the MIME strukture in a list > > - then call translating functions that insert the appropriate >delimeters > what does it look like (in the text WL buffer) when you attach say an image, or a piece of inline text like a diff file? If WL has it's own mime markup like mml that would be ideal. > >>I've just made a couple of small changes, and pushed this file up to a >>git repo at http://github.com/eschulte/org-html-mail, or for raw elisp >>http://github.com/eschulte/org-html-mail/raw/master/org-mml-htmlize.el > > Just out of curiosity: Why do you write to a temp file and not just > insert the body in a temporary buffer, turn on org-mode and use > org-export-region-as-html (point-min) (point-max) nil t 'string)? > Because `org-export-as-html' requires that the buffer have a path, I believe this is for resolution of relative paths for things like images. Best -- Eric > > -- David > > -- > OpenPGP... 0x99ADB83B5A4478E6 > Jabber dmj...@jabber.org > Email. dm...@ictsoc.de ___ 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
Re: [Orgmode] using orgmode to send html mail?
Eric Schulte wrote: >Thanks Dan, >I'm happy to hear I'm not the only person who's enjoying playing with >this :). >Aside from changing the mime-delimeters for VM and wanderlust, it seems >to me that the only remaining step between the current functionality and >a seamless use of org-mode for email composition, is the resolution of >images as email attachments. That would allow emails with embedded >latex (which I personally would find very compelling), as well as >embedded ditaa diagrams and images. If anyone knows more about mime, >I'd be interested to hear suggestions, but I may try a first pass using >`replace-regexp' to replace all links with inline mime image >attachments. Taking a look into the MIME specs (RFC2045ff) regarding this issue is on my list. My biggest concern with utilizing more MIME capabilities is, that you have little control over what the recipient's MUA will do. Don't know about VM, but with regards to WL I'd imagine something like: - first represent the MIME strukture in a list - then call translating functions that insert the appropriate delimeters >I've just made a couple of small changes, and pushed this file up to a >git repo at http://github.com/eschulte/org-html-mail, or for raw elisp >http://github.com/eschulte/org-html-mail/raw/master/org-mml-htmlize.el Just out of curiosity: Why do you write to a temp file and not just insert the body in a temporary buffer, turn on org-mode and use org-export-region-as-html (point-min) (point-max) nil t 'string)? -- David -- OpenPGP... 0x99ADB83B5A4478E6 Jabber dmj...@jabber.org Email. dm...@ictsoc.de pgpGEnFi7I6tY.pgp Description: PGP signature ___ 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
Re: [Orgmode] using orgmode to send html mail?
Thanks Dan, I'm happy to hear I'm not the only person who's enjoying playing with this :). Aside from changing the mime-delimeters for VM and wanderlust, it seems to me that the only remaining step between the current functionality and a seamless use of org-mode for email composition, is the resolution of images as email attachments. That would allow emails with embedded latex (which I personally would find very compelling), as well as embedded ditaa diagrams and images. If anyone knows more about mime, I'd be interested to hear suggestions, but I may try a first pass using `replace-regexp' to replace all links with inline mime image attachments. I've just made a couple of small changes, and pushed this file up to a git repo at http://github.com/eschulte/org-html-mail, or for raw elisp http://github.com/eschulte/org-html-mail/raw/master/org-mml-htmlize.el Cheers -- Eric Dan Davison writes: > "Eric Schulte" writes: > >> Xiao-Yong Jin writes: >> >>> On Tue, 23 Mar 2010 13:54:39 -0600, Eric Schulte wrote: >>> Nice to see this topic has come back to life. I've been playing with my old org-html-mail.el file, and come up with a much simpler solution, which takes advantage of the mml message mode functionality with is used in gnus (and I would imagine in some other Emacs mail clients, but I can't be sure). >>> Just call this function and either the active region of your message buffer or the entire body (if no region is active) will be exported to html using org-mode, and will be wrapped in the appropriate mml wrapper to be sent as the appropriate mime type. >>> >> >> I've cleaned up the function somewhat, I'll include it immediately >> below by inserting it in a org-mode src_block and then exporting it to >> html, so those with html mail readers should see a nicely fontified >> version of the source code. > > This is really nice. I already sent my first HTML-formatted tables to > colleagues with it yesterday. And yes, the email comes up with nicely > formatted elisp in my web browser after hitting 'K H' in gnus. > > Dan > >> >> (defun org-mml-htmlize (arg) >> "Export a portion of an email body composed using `mml-mode' to >> html using `org-mode'. If called with an active region only >> export that region, otherwise export the entire body." >> (interactive "P") >> (let* ((region-p (org-region-active-p)) >> (html-start (or (and region-p (region-beginning)) >> (save-excursion >>(goto-char (point-min)) >>(search-forward mail-header-separator) >>(point >> (html-end (or (and region-p (region-end)) >>;; TODO: should catch signature... >>(point-max))) >> (body (buffer-substring html-start html-end)) >> (tmp-file (make-temp-name (expand-file-name "mail" "/tmp/"))) >> ;; because we probably don't want to skip part of our mail >> (org-export-skip-text-before-1st-heading nil) >> ;; because we probably don't want to export a huge style file >> (org-export-htmlize-output-type 'inline-css) >> ;; makes the replies with ">"s look nicer >> (org-export-preserve-breaks t) >> (html (if arg >>(format "> monospace;\">\n%s\n" body) >> (save-excursion >>(with-temp-buffer >> (insert body) >> (write-file tmp-file) >> ;; convert to html -- mimicing >> `org-run-like-in-org-mode' >> (eval (list 'let org-local-vars >> (list 'org-export-as-html nil nil nil >> ''string t >> (delete-region html-start html-end) >> (save-excursion >> (goto-char html-start) >> (insert >>(format >> "\n<#multipart type=alternative>\n<#part >> type=text/html>%s<#/multipart>\n" >> html) >> >> >>> >>> Thumbs up for this one. It should be included in >>> org-contrib, probably after taken care of other mail client >>> in emacs? >>> >> >> I have looked somewhat at both VM and Wanderlust, but they appear to use >> their own mime encoding schemes other than mml, so this won't work as-is >> in those mail clients. That said, assuming they also use simple mime >> encoding strings it should be hard to replace the mml specific mime >> delimiters presented as strings in the above functions with string >> delimiters appropriate for the other mail agents. >> >> also, I have to say I feel bad about publishing code which promotes the >> use of HTML mail. Generally I feel that everyone would be better off if >> they just used fixed width text email clients. As a concession to that >> intuition, if this function is called with a prefix argument, it will >> wrap the region (or entire email) as html in tags ensuring >> that it will be r
Re: [Orgmode] using orgmode to send html mail?
"Eric Schulte" writes: > Xiao-Yong Jin writes: > >> On Tue, 23 Mar 2010 13:54:39 -0600, Eric Schulte wrote: >> >>> Nice to see this topic has come back to life. >>> I've been playing with my old org-html-mail.el file, and come up with a >>> much simpler solution, which takes advantage of the mml message mode >>> functionality with is used in gnus (and I would imagine in some other >>> Emacs mail clients, but I can't be sure). >> >>> Just call this function and either the active region of your message >>> buffer or the entire body (if no region is active) will be exported to >>> html using org-mode, and will be wrapped in the appropriate mml wrapper >>> to be sent as the appropriate mime type. >> > > I've cleaned up the function somewhat, I'll include it immediately > below by inserting it in a org-mode src_block and then exporting it to > html, so those with html mail readers should see a nicely fontified > version of the source code. This is really nice. I already sent my first HTML-formatted tables to colleagues with it yesterday. And yes, the email comes up with nicely formatted elisp in my web browser after hitting 'K H' in gnus. Dan > > (defun org-mml-htmlize (arg) > "Export a portion of an email body composed using `mml-mode' to > html using `org-mode'. If called with an active region only > export that region, otherwise export the entire body." > (interactive "P") > (let* ((region-p (org-region-active-p)) > (html-start (or (and region-p (region-beginning)) > (save-excursion >(goto-char (point-min)) >(search-forward mail-header-separator) >(point > (html-end (or (and region-p (region-end)) >;; TODO: should catch signature... >(point-max))) > (body (buffer-substring html-start html-end)) > (tmp-file (make-temp-name (expand-file-name "mail" "/tmp/"))) > ;; because we probably don't want to skip part of our mail > (org-export-skip-text-before-1st-heading nil) > ;; because we probably don't want to export a huge style file > (org-export-htmlize-output-type 'inline-css) > ;; makes the replies with ">"s look nicer > (org-export-preserve-breaks t) > (html (if arg >(format " monospace;\">\n%s\n" body) > (save-excursion >(with-temp-buffer > (insert body) > (write-file tmp-file) > ;; convert to html -- mimicing `org-run-like-in-org-mode' > (eval (list 'let org-local-vars > (list 'org-export-as-html nil nil nil > ''string t > (delete-region html-start html-end) > (save-excursion > (goto-char html-start) > (insert >(format > "\n<#multipart type=alternative>\n<#part > type=text/html>%s<#/multipart>\n" > html) > > >> >> Thumbs up for this one. It should be included in >> org-contrib, probably after taken care of other mail client >> in emacs? >> > > I have looked somewhat at both VM and Wanderlust, but they appear to use > their own mime encoding schemes other than mml, so this won't work as-is > in those mail clients. That said, assuming they also use simple mime > encoding strings it should be hard to replace the mml specific mime > delimiters presented as strings in the above functions with string > delimiters appropriate for the other mail agents. > > also, I have to say I feel bad about publishing code which promotes the > use of HTML mail. Generally I feel that everyone would be better off if > they just used fixed width text email clients. As a concession to that > intuition, if this function is called with a prefix argument, it will > wrap the region (or entire email) as html in tags ensuring > that it will be rendered in a fixed-with font no-matter the receivers > email client, so the following table should actually look like a > table... > > | this table | | n | fibb(n) | > |--+---+---+-| > | is | | 0 | 0 | > | inside | | 1 | 1 | > | of a pre box | | 2 | 1 | > | | | 3 | 2 | > > > Best -- Eric > >> >>> So for example this 1 | 2 | 3 | --++---| first column | second | third | >> >>> will be exported as this >>> ━━ >>>1 2 3 >>> ── >>> first column second third >>> ━━ >> >> I use emacs-w3m in gnus, and the table looks great. > ___ > 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 ___ Emacs-orgmode mailing list Pleas
Re: [Orgmode] using orgmode to send html mail?
Xiao-Yong Jin writes: > On Tue, 23 Mar 2010 13:54:39 -0600, Eric Schulte wrote: > >> Nice to see this topic has come back to life. >> I've been playing with my old org-html-mail.el file, and come up with a >> much simpler solution, which takes advantage of the mml message mode >> functionality with is used in gnus (and I would imagine in some other >> Emacs mail clients, but I can't be sure). > >> Just call this function and either the active region of your message >> buffer or the entire body (if no region is active) will be exported to >> html using org-mode, and will be wrapped in the appropriate mml wrapper >> to be sent as the appropriate mime type. > I've cleaned up the function somewhat, I'll include it immediately below by inserting it in a org-mode src_block and then exporting it to html, so those with html mail readers should see a nicely fontified version of the source code. (defun org-mml-htmlize (arg) "Export a portion of an email body composed using `mml-mode' to html using `org-mode'. If called with an active region only export that region, otherwise export the entire body." (interactive "P") (let* ((region-p (org-region-active-p)) (html-start (or (and region-p (region-beginning)) (save-excursion (goto-char (point-min)) (search-forward mail-header-separator) (point (html-end (or (and region-p (region-end)) ;; TODO: should catch signature... (point-max))) (body (buffer-substring html-start html-end)) (tmp-file (make-temp-name (expand-file-name "mail" "/tmp/"))) ;; because we probably don't want to skip part of our mail (org-export-skip-text-before-1st-heading nil) ;; because we probably don't want to export a huge style file (org-export-htmlize-output-type 'inline-css) ;; makes the replies with ">"s look nicer (org-export-preserve-breaks t) (html (if arg (format "\n%s\n" body) (save-excursion (with-temp-buffer (insert body) (write-file tmp-file) ;; convert to html -- mimicing `org-run-like-in-org-mode' (eval (list 'let org-local-vars (list 'org-export-as-html nil nil nil ''string t (delete-region html-start html-end) (save-excursion (goto-char html-start) (insert (format "\n<#multipart type=alternative>\n<#part type=text/html>%s<#/multipart>\n" html) > > Thumbs up for this one. It should be included in > org-contrib, probably after taken care of other mail client > in emacs? > I have looked somewhat at both VM and Wanderlust, but they appear to use their own mime encoding schemes other than mml, so this won't work as-is in those mail clients. That said, assuming they also use simple mime encoding strings it should be hard to replace the mml specific mime delimiters presented as strings in the above functions with string delimiters appropriate for the other mail agents. also, I have to say I feel bad about publishing code which promotes the use of HTML mail. Generally I feel that everyone would be better off if they just used fixed width text email clients. As a concession to that intuition, if this function is called with a prefix argument, it will wrap the region (or entire email) as html in tags ensuring that it will be rendered in a fixed-with font no-matter the receivers email client, so the following table should actually look like a table... | this table | | n | fibb(n) | |--+---+---+-| | is | | 0 | 0 | | inside | | 1 | 1 | | of a pre box | | 2 | 1 | | | | 3 | 2 | Best -- Eric > >> So for example this >>> 1 | 2 | 3 | >>> --++---| >>> first column | second | third | > >> will be exported as this >> ━━ >>1 2 3 >> ── >> first column second third >> ━━ > > I use emacs-w3m in gnus, and the table looks great. ___ 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
Re: [Orgmode] using orgmode to send html mail?
On Tue, 23 Mar 2010 13:54:39 -0600, Eric Schulte wrote: > Nice to see this topic has come back to life. > I've been playing with my old org-html-mail.el file, and come up with a > much simpler solution, which takes advantage of the mml message mode > functionality with is used in gnus (and I would imagine in some other > Emacs mail clients, but I can't be sure). > Just call this function and either the active region of your message > buffer or the entire body (if no region is active) will be exported to > html using org-mode, and will be wrapped in the appropriate mml wrapper > to be sent as the appropriate mime type. Thumbs up for this one. It should be included in org-contrib, probably after taken care of other mail client in emacs? > So for example this >> 1 | 2 | 3 | >> --++---| >> first column | second | third | > will be exported as this > ━━ >1 2 3 > ── > first column second third > ━━ I use emacs-w3m in gnus, and the table looks great. -- Jc/*__o/* X<\ * (__ Y*/\ < ___ 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
Re: [Orgmode] using orgmode to send html mail?
Nice to see this topic has come back to life. I've been playing with my old org-html-mail.el file, and come up with a much simpler solution, which takes advantage of the mml message mode functionality with is used in gnus (and I would imagine in some other Emacs mail clients, but I can't be sure). Just call this function and either the active region of your message buffer or the entire body (if no region is active) will be exported to html using org-mode, and will be wrapped in the appropriate mml wrapper to be sent as the appropriate mime type. So for example this |1 | 2 | 3 | |--++---| | first column | second | third | will be exported as this 123 first columnsecondthird The function is provided in the attached file. org-mml-htmlize.el Description: application/emacs-lisp Best -- Eric David Maus writes: > Matt Price wrote: >>Hi, > >>I just wondered whether anyone composes mail in orgmode & then >>generates html from the source code. I'd like to be able to do that >>sometimes in wanderlust, e.g. when I'm responding to html mail with >>links in it. > > Just pushed to hacks to Worg on how to send html messages in > Wanderlust using Org's html exporter and how to attach html markup of > a region or subtree in Wanderlust. Latter is a follow-up on > > http://lists.gnu.org/archive/html/emacs-orgmode/2009-11/msg00746.html > > Until Worg picks it up: > > 1 Send html messages and attachments with Wanderlust > ~ > -- David Maus > > These two hacks below add the capability of using Org to send out html > via email. Both focus on Wanderlust but could be easily adopted for > Gnus, I think. > > 1.1 Send HTML message > == > > Putting the code below in your .emacs adds following four functions: > >- dmj/wl-send-html-message > > Function that does the job: Convert everything between "--text > follows this line--" and first mime entity (read: attachment) or > end of buffer into HTML markup using `org-export-region-as-html' > and replaces original body with a mime entity of text/html, > content-disposition: inline. Line breaks of the signature are > preserved. > > Cannot be called interactively: It is hooked into SEMI's > `mime-edit-translate-hook' if message should be HTML message. > >- dmj/wl-send-html-message-draft-init > > Cannot be called interactively: It is hooked into WL's > `wl-mail-setup-hook' and `wl-draft-reedit-hook' and provides a > buffer local variable to toggle. > >- dmj/wl-send-html-message-draft-maybe > > Cannot be called interactively: It is hooked into WL's > `wl-draft-send-hook' and hooks `dmj/wl-send-html-message' into > `mime-edit-translate-hook' depending on whether HTML message is > toggled on or off > >- dmj/wl-send-html-message-toggle > > Toggles sending of HTML message. If toggled on, the letters > "HTML" appear in the mode line. > > Call it interactively! Or bind it to a key in `wl-draft-mode'. > > If you have to send HTML messages regularly you can set a global > variable `dmj/wl-send-html-message-toggled-p' to the string "HTML" to > toggle on sending HTML message by default. > > The image [here] shows an example of how the HTML message looks like in > Google's web front end. As you can see you have the whole markup of > Org at your service: *bold*, /italics/, tables, lists... > > So even if you feel uncomfortable with sending HTML messages at least > you send HTML that looks quite good. > > > (defun dmj/wl-send-html-message () > "Send message as html message. > Convert body of message to html using > `org-export-region-as-html'." > (require 'org) > (save-excursion > (let (beg end html text) > (goto-char (point-min)) > (re-search-forward "^--text follows this line--$") > ;; move to beginning of next line > (beginning-of-line 2) > (setq beg (point)) > (if (not (re-search-forward "^--\\[\\[" nil t)) > (setq end (point-max)) > ;; line up > (end-of-line 0) > (setq end (point))) > ;; grab body > (setq text (buffer-substring-no-properties beg end)) > ;; convert to html > (with-temp-buffer > (org-mode) > (insert text) > ;; handle signature > (when (re-search-backward "^-- \n" nil t) > ;; preserve link breaks in signature > (insert "\n#+BEGIN_VERSE\n") > (goto-char (point-max)) > (insert "\n#+END_VERSE\n") > ;; grab html > (setq html (org-export-region-as-html > (point-min) (point-max) t 'string > (delete-region beg end) > (insert > (concat > "--[text/html\nContent-Disposition: inline]\n" > html) > > (defun dmj/wl-send
Re: [Orgmode] using orgmode to send html mail?
Matt Price wrote: >Hi, >I just wondered whether anyone composes mail in orgmode & then >generates html from the source code. I'd like to be able to do that >sometimes in wanderlust, e.g. when I'm responding to html mail with >links in it. Just pushed to hacks to Worg on how to send html messages in Wanderlust using Org's html exporter and how to attach html markup of a region or subtree in Wanderlust. Latter is a follow-up on http://lists.gnu.org/archive/html/emacs-orgmode/2009-11/msg00746.html Until Worg picks it up: 1 Send html messages and attachments with Wanderlust ~ -- David Maus These two hacks below add the capability of using Org to send out html via email. Both focus on Wanderlust but could be easily adopted for Gnus, I think. 1.1 Send HTML message == Putting the code below in your .emacs adds following four functions: - dmj/wl-send-html-message Function that does the job: Convert everything between "--text follows this line--" and first mime entity (read: attachment) or end of buffer into HTML markup using `org-export-region-as-html' and replaces original body with a mime entity of text/html, content-disposition: inline. Line breaks of the signature are preserved. Cannot be called interactively: It is hooked into SEMI's `mime-edit-translate-hook' if message should be HTML message. - dmj/wl-send-html-message-draft-init Cannot be called interactively: It is hooked into WL's `wl-mail-setup-hook' and `wl-draft-reedit-hook' and provides a buffer local variable to toggle. - dmj/wl-send-html-message-draft-maybe Cannot be called interactively: It is hooked into WL's `wl-draft-send-hook' and hooks `dmj/wl-send-html-message' into `mime-edit-translate-hook' depending on whether HTML message is toggled on or off - dmj/wl-send-html-message-toggle Toggles sending of HTML message. If toggled on, the letters "HTML" appear in the mode line. Call it interactively! Or bind it to a key in `wl-draft-mode'. If you have to send HTML messages regularly you can set a global variable `dmj/wl-send-html-message-toggled-p' to the string "HTML" to toggle on sending HTML message by default. The image [here] shows an example of how the HTML message looks like in Google's web front end. As you can see you have the whole markup of Org at your service: *bold*, /italics/, tables, lists... So even if you feel uncomfortable with sending HTML messages at least you send HTML that looks quite good. (defun dmj/wl-send-html-message () "Send message as html message. Convert body of message to html using `org-export-region-as-html'." (require 'org) (save-excursion (let (beg end html text) (goto-char (point-min)) (re-search-forward "^--text follows this line--$") ;; move to beginning of next line (beginning-of-line 2) (setq beg (point)) (if (not (re-search-forward "^--\\[\\[" nil t)) (setq end (point-max)) ;; line up (end-of-line 0) (setq end (point))) ;; grab body (setq text (buffer-substring-no-properties beg end)) ;; convert to html (with-temp-buffer (org-mode) (insert text) ;; handle signature (when (re-search-backward "^-- \n" nil t) ;; preserve link breaks in signature (insert "\n#+BEGIN_VERSE\n") (goto-char (point-max)) (insert "\n#+END_VERSE\n") ;; grab html (setq html (org-export-region-as-html (point-min) (point-max) t 'string (delete-region beg end) (insert (concat "--[text/html\nContent-Disposition: inline]\n" html) (defun dmj/wl-send-html-message-toggle () "Toggle sending of html message." (interactive) (setq dmj/wl-send-html-message-toggled-p (if dmj/wl-send-html-message-toggled-p nil "HTML")) (message "Sending html message toggled %s" (if dmj/wl-send-html-message-toggled-p "on" "off"))) (defun dmj/wl-send-html-message-draft-init () "Create buffer local settings for maybe sending html message." (unless (boundp 'dmj/wl-send-html-message-toggled-p) (setq dmj/wl-send-html-message-toggled-p nil)) (make-variable-buffer-local 'dmj/wl-send-html-message-toggled-p) (add-to-list 'global-mode-string '(:eval (if (eq major-mode 'wl-draft-mode) dmj/wl-send-html-message-toggled-p (defun dmj/wl-send-html-message-maybe () "Maybe send this message as html message. If buffer local variable `dmj/wl-send-html-message-toggled-p' is non-nil, add `dmj/wl-send-html-message' to `mime-edit-translate-hook'." (if dmj/wl-send-html-
