From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eric Schulte" Subject: Re: using orgmode to send html mail? Date: Wed, 31 Mar 2010 16:03:50 -0600 Message-ID: <87k4ssb12n.fsf@gmail.com> References: <878w9krtyn.wl%dmaus@ictsoc.de> <871vfa24qo.fsf@gmail.com> <87pr2uww2d.fsf@columbia.edu> <87tys5zrwm.fsf@gmail.com> <87sk7pzk02.fsf@stats.ox.ac.uk> <87tys5r3q6.fsf@gmail.com> <87ocid7cuj.wl%dmaus@ictsoc.de> <874ok5qxp9.fsf@gmail.com> <87vdckksnj.wl%dmaus@ictsoc.de> <874ok33zje.fsf@gmail.com> <87zl1vf4ru.wl%dmaus@ictsoc.de> <874ok311t9.fsf@gmail.com> <87y6h8tegw.wl%dmaus@ictsoc.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nx63h-0003AQ-02 for emacs-orgmode@gnu.org; Wed, 31 Mar 2010 18:06:45 -0400 Received: from [140.186.70.92] (port=49734 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nx63e-0002fQ-QR for emacs-orgmode@gnu.org; Wed, 31 Mar 2010 18:06:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nx61A-0004rN-Rt for emacs-orgmode@gnu.org; Wed, 31 Mar 2010 18:04:11 -0400 Received: from mail-pz0-f191.google.com ([209.85.222.191]:40930) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nx61A-0004rA-ES for emacs-orgmode@gnu.org; Wed, 31 Mar 2010 18:04:08 -0400 Received: by pzk29 with SMTP id 29so638845pzk.27 for ; Wed, 31 Mar 2010 15:04:04 -0700 (PDT) List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: David Maus Cc: Dan Davison , emacs-orgmode@gnu.org 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, blink tags around every noun > > > > -- > OpenPGP... 0x99ADB83B5A4478E6 > Jabber.... dmjena@jabber.org > Email..... dmaus@ictsoc.de Footnotes: [1] http://github.com/eschulte/org-mime