[david.reitter@gmail.com: mailclient.el - revised]

[david.reitter@gmail.com: mailclient.el - revised]

[Richard M. Stallman]

Could people please take a look at this, and comment to me and David?

------- Start of forwarded message -------
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:mime-version:to:message-id:content-type:from:subject:date:x-mailer;
        b=hbHyaITmyvQOezM5ZQKLOkFKJjo/G20TJwCfIJZGbboSMF+W/VnlpJIfAS4oCrd8p82kzcs0UTQCM8Ygjg03tBEDuBj/YdN4Sb1Byrs8MtXG1owj6aT6t+KsVXaYxpyQxPm4zinNu/wJUponqBFLojv5PwZq+I3HgfZn87hHDAE=
To: Richard Stallman <rms@gnu.org>
From: David Reitter <david.reitter@gmail.com>
Subject: mailclient.el - revised
Date: Wed, 20 Jul 2005 11:20:19 +0100
X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on monty-python
X-Spam-Level: 
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63


- --Apple-Mail-19--333784832
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

Hi,

I'm attaching a revised version of the proposed lisp/mail/mailclient.el.
The old one had problems when compiling and didn't include an  
autoload comment. I also rewrote mailclient-encode-string-as-url,  
because the function it replaces was taken from w3m.

Papers have been signed and should already be at your office.



- --Apple-Mail-19--333784832
Content-Transfer-Encoding: 7bit
Content-Type: application/octet-stream;
	x-unix-mode=0644;
	x-mac-creator=454D4178;
	name="mailclient.el"
Content-Disposition: attachment;
	filename=mailclient.el

;;; mailclient.el --- mail sending via system's mail client.  -*- byte-compile-dynamic: t -*-

;; Copyright (C) 2005 Free Software Foundation

;; Maintainer: David Reitter <david.reitter@gmail.com>
;; Keywords: mail

;; This file is part of GNU Emacs.

;; GNU Emacs is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation; either version 2, or (at your option)
;; any later version.

;; GNU Emacs is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with GNU Emacs; see the file COPYING.  If not, write to the
;; Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
;; Boston, MA 02110-1301, USA.

;;; Commentary:

;; This package allows to hand over a buffer to be sent off 
;; via the system's designated e-mail client. 
;; Note that the e-mail client will display the contents of the buffer
;; again for editing.
;; The e-mail client is taken to be whoever handles a mailto: URL
;; via `browse-url'.
;; To activate:
;; (setq send-mail-function 'mailclient-send-it) ; if you use `mail'

;;; Code:


(require 'sendmail) ;; for mail-sendmail-undelimit-header

(defun mailclient-encode-string-as-url (string)
  "Convert STRING to a URL, using utf-8 as encoding."
  (apply (function concat)
	 (mapcar
	  (lambda (char)
	    (cond
	     ((eq char ?\x20) "%20")   ;; space
	     ((eq char ?\n) "%0D%0A")  ;; newline 
	     ((string-match "[-a-zA-Z0-9_:/.@]" (char-to-string char))
	      (char-to-string char))   ;; printable
	     (t                        ;; everything else
	      (format "%%%02x" char))))	;; escape
	  ;; Convert string to list of chars
	  (append (encode-coding-string string 'utf-8)))))

(defvar mailclient-delim-static "?")
(defun mailclient-url-delim ()
	      (let ((current mailclient-delim-static))
		(setq mailclient-delim-static "&") 
		current))

(defun mailclient-gather-addresses (str delimline &optional drop-first-name)
  (let ((cc "")
	end) 
    (goto-char (point-min))
    ;; find all cc's
    (while
	(re-search-forward 
	 (format "^%s:[ ]*" (upcase-initials str)) delimline t)
      (let ((beg (point)))
	(re-search-forward "\n" delimline t)
	(setq end (point))
	(goto-char beg))
      (while 
	  (re-search-forward "[ ]*\\([^ ,\n]+\\)" end t) 
	(setq cc 
	      (concat cc  
		      (if (and drop-first-name
			       (= (length cc) 0))
			  ""
			  (concat (mailclient-url-delim) str "="))
		      (mailclient-encode-string-as-url 
		       (match-string 1))))))
    cc))


;;;###autoload
(defun mailclient-send-it () 
  "Pass current buffer on to the system's mail client.
Suitable value for `send-mail-function'.
The mail client is taken to be the handler of mailto URLs."
  (let ((case-fold-search nil)
	delimline
	(mailbuf (current-buffer))
	(tembuf (generate-new-buffer " mailclient temp")))
    (unwind-protect
	(save-excursion
	  (set-buffer tembuf)
	  (erase-buffer)
	  (insert-buffer-substring mailbuf)
	  ;; Move to header delimiter
	  (mail-sendmail-undelimit-header)
	  (setq delimline (point-marker))
	  (if mail-aliases
	      (expand-mail-aliases (point-min) delimline))
	  (goto-char (point-min))
	  ;; ignore any blank lines in the header
	  (while (and (re-search-forward "\n\n\n*" delimline t)
		      (< (point) delimline))
	    (replace-match "\n"))
	  (let ((case-fold-search t))  
	    ;; initialize limiter
	    (setq mailclient-delim-static "?")
	    ;; construct and call up mailto URL
	    (browse-url 
	     (concat "mailto:"
		     (mailclient-gather-addresses "to" delimline 
						  'drop-first-name)	       
		     (mailclient-gather-addresses "cc" delimline)
		     (mailclient-gather-addresses "bcc" delimline)
		     (mailclient-gather-addresses "reply-to" delimline)
		     ;; subject line
		     (if (and (goto-char (point-min))
			      (re-search-forward 
			       "^Subject:\s*\\([^\n]*[^ ]\\)\n" delimline t))
			 (concat (mailclient-url-delim) "subject=" 
				 (mailclient-encode-string-as-url 
				  (match-string 1)))
		       "")
		     ;; body
		     (concat (mailclient-url-delim) "body=" 
			     (mailclient-encode-string-as-url 
			      (buffer-substring delimline (point-max))))))))  
      (kill-buffer tembuf))))

(provide 'mailclient)
- --Apple-Mail-19--333784832--
------- End of forwarded message -------

Re: [david.reitter@gmail.com: mailclient.el - revised]

[Lennart Borgman]

Richard M. Stallman wrote:

>Could people please take a look at this, and comment to me and David?
>  
>
I sent some suggestions earlier on what to do to get this working on w32 
too. Could these please be included?

Re: [david.reitter@gmail.com: mailclient.el - revised]

[David Reitter]

On 24 Jul 2005, at 01:17, Lennart Borgman wrote:

> I sent some suggestions earlier on what to do to get this working  
> on w32 too. Could these please be included?

Ok, you mean using mailclient-send-it as default for send-mail- 
function not only in Darwin, but also on Windows?
Sounds good to me, except that it'd be good if you test it with one  
or two common mailclients, because I can't.

Re: [david.reitter@gmail.com: mailclient.el - revised]

[Lennart Borgman]

David Reitter wrote:

> On 24 Jul 2005, at 01:17, Lennart Borgman wrote:
>
>> I sent some suggestions earlier on what to do to get this working  on 
>> w32 too. Could these please be included?
>
>
> Ok, you mean using mailclient-send-it as default for send-mail- 
> function not only in Darwin, but also on Windows?
> Sounds good to me, except that it'd be good if you test it with one  
> or two common mailclients, because I can't.
>
I did test it with ThunderBird.

However it should not depend on the mail client used. In w32 there is a 
problem with the parameter length when passing the URL to w32. I have 
done a workaround placing data on the clipboard.  Otherwise (browse-url 
...) for the "mailto:..." URL is used just as in your original code.

Re: [david.reitter@gmail.com: mailclient.el - revised]

[David Reitter]

On 24 Jul 2005, at 15:46, Lennart Borgman wrote:

>  However it should not depend on the mail client used. In w32 there  
> is a problem with the parameter length when passing the URL to w32.  
> I have done a workaround placing data on the clipboard.  Otherwise  
> (browse-url ...) for the "mailto:..." URL is used just as in your  
> original code.

I don't think placing data on the clipboard and asking the user to  
copy it over would be the ideal solution. Using MAPI (instead of  
mailclient) seems to be the correct way to do things on Windows.
The reason that I didn't propose mailclient as default on Win  
originally was exactly what you said: I heard that the URL length is  
limited, at least under certain circumstances.

I guess it would be best to not use mailclient as default on Windows  
and hope that someone (you?) will implement MAPI functionality...
If people use a variety of Win / a URL client that supports long  
URLs, they can still set the send-mail-function to mailclient.

Re: [david.reitter@gmail.com: mailclient.el - revised]

[Jason Rumney]

David Reitter wrote:

> On 24 Jul 2005, at 15:46, Lennart Borgman wrote:
>
>>  However it should not depend on the mail client used. In w32 there  
>> is a problem with the parameter length when passing the URL to w32.  
>> I have done a workaround placing data on the clipboard.  Otherwise  
>> (browse-url ...) for the "mailto:..." URL is used just as in your  
>> original code.
>
>
> I don't think placing data on the clipboard and asking the user to  
> copy it over would be the ideal solution. Using MAPI (instead of  
> mailclient) seems to be the correct way to do things on Windows.

MAPI is a proprietary API for proprietary mail clients on a proprietary 
OS. It is not the "correct" way for anything. Free mail clients such as 
Emacs, Mozilla Thunderbird and others are not supported by MAPI.

mailto: urls are an open standard. They can be made to work with any 
mail client that has a command-line interface, even Emacs (see the Emacs 
on Windows FAQ). If there are limitations with them on Windows, then 
that is something that Windows users have to live with. What Lennart 
suggested seems like a good comprimise, even if not ideal, but itshould 
be conditioned on whether the user has customized send-mail-function, 
since there is a high chance that Emacs will be able to send mail (using 
smtpmail.el for example) if the user has configured it to (this applies 
to Mac as well). This may be the case already, I haven't studied the 
code you wrote.

Re: [david.reitter@gmail.com: mailclient.el - revised]

[Lennart Borgman]

David Reitter wrote:

> I don't think placing data on the clipboard and asking the user to  
> copy it over would be the ideal solution. Using MAPI (instead of  
> mailclient) seems to be the correct way to do things on Windows.
> The reason that I didn't propose mailclient as default on Win  
> originally was exactly what you said: I heard that the URL length is  
> limited, at least under certain circumstances.
>
> I guess it would be best to not use mailclient as default on Windows  
> and hope that someone (you?) will implement MAPI functionality...
> If people use a variety of Win / a URL client that supports long  
> URLs, they can still set the send-mail-function to mailclient.

I agree, but at the moment I feel that placing data on the clipboard is 
a good workaround. At the moment I do not have time to implement MAPI 
support and I do not even know if it is welcome.

So I suggest that my workaround is adopted.

Re: [david.reitter@gmail.com: mailclient.el - revised]

[Lennart Borgman]

Jason Rumney wrote:

>
> MAPI is a proprietary API for proprietary mail clients on a 
> proprietary OS. It is not the "correct" way for anything. Free mail 
> clients such as Emacs, Mozilla Thunderbird and others are not 
> supported by MAPI.
>
> mailto: urls are an open standard. They can be made to work with any 
> mail client that has a command-line interface, even Emacs (see the 
> Emacs on Windows FAQ). If there are limitations with them on Windows, 
> then that is something that Windows users have to live with. What 
> Lennart suggested seems like a good comprimise, even if not ideal, but 
> itshould be conditioned on whether the user has customized 
> send-mail-function, since there is a high chance that Emacs will be 
> able to send mail (using smtpmail.el for example) if the user has 
> configured it to (this applies to Mac as well). This may be the case 
> already, I haven't studied the code you wrote.

I did a search on the web and actually it looks like MAPI is supported 
by Thunderbird.

Re: [david.reitter@gmail.com: mailclient.el - revised]

[David Reitter]

On 28 Jul 2005, at 13:24, Jason Rumney wrote:
>
> MAPI is a proprietary API for proprietary mail clients on a  
> proprietary OS. It is not the "correct" way for anything. Free mail  
> clients such as Emacs, Mozilla Thunderbird and others are not  
> supported by MAPI.
>
> mailto: urls are an open standard. They can be made to work with  
> any mail client that has a command-line interface, even Emacs (see  
> the Emacs on Windows FAQ). If there are limitations with them on  
> Windows, then that is something that Windows users have to live with.

It seems that you misunderstand what the task is that we're trying to  
achieve. That is, to send off an e-mail without further interaction.  
mailto URLs are an open standard, but they are a standard for the  
wrong thing. They should be adopted when there is no other  
possibility, as is the case on Mac OS X / Darwin (in default  
configuration). So on OS X, we need a workaround - one that actually  
provides a useful functionality on all systems provided mailto URLs  
are fully supported.

Unless I'm mistaken here, MAPI offers a way to send off e-mails  
without user interaction. Hundreds of viruses have used this API on  
Windows, so it must be there :) For that functionality, MAPI dlls  
seem to take on the responsibilities that we would normally expect  
from sendmail.

Why is MAPI proprietary?  I mean, the idea is that mail clients can  
support their own mapi32.dll, right? So the API is open and  
documented, correct? And in fact, the very non-proprietary mail  
client Mozilla Thunderbird seems to implement it...

Apart from that, even if you're using functions for which you don't  
have source and the usual freedoms - how do you justify using the  
Win32API that makes windows pop up or sends a document to the printer?


> What Lennart suggested seems like a good comprimise, even if not  
> ideal, but itshould be conditioned on whether the user has  
> customized send-mail-function, since there is a high chance that  
> Emacs will be able to send mail (using smtpmail.el for example) if  
> the user has configured it to (this applies to Mac as well). This  
> may be the case already, I haven't studied the code you wrote.

Yes, they should depend on send-mail-function, and it seems to me  
that you haven't really read the thread, since 'mailclient-send-it  
for send-mail-function is what others and I have been suggesting all  
along.