[Top][All Lists]

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

Re: send-mail-function / mailclient

From: David Reitter
Subject: Re: send-mail-function / mailclient
Date: Tue, 27 Jan 2009 08:48:00 -0500

On 20 Jan 2009, at 15:25, Lennart Borgman wrote:

When this was discussed some time ago a workaround was implemented for
w32. I think this can be used on most platforms.

With this workaround you can edit the data in both Emacs and the mail
client. When you finish editing the mail message in Emacs the users
mail client is started to edit a new mail message. This message has
the subject from Emacs, but the body just says

That is a clean, working solution. Any application that sends e-mail will have the problem of making users configure mail servers. Thus, I would find it acceptable to use mailclient as default. It would be important to point people to `send-mail-function' when they configure the mail servers (i.e. in the appropriate doc strings at least). It is clear that mailclient makes no sense once somebody uses Emacs for mail...

Similarly, M-x report-emacs-bug wasn't conceived for such an arrangement:

- Buffers are edited twice - once in Emacs, and then again in the mail client. The mailto:// protocol wasn't designed to handle full messages to
be sent off without editing.  We're abusing the protocol.


- What happens if Emacs is used as mailto:// handler?  At least on my
system, we don't provide the function directly, but in principle, users should be able to do this. If GNU/Linux has some kind of accepted standard to announce "I can handle xxx:// URLs", then perhaps we should implement it
(for all systems).

Perhaps GNU/Linux doesn't offer a central way to advertise URL protocol handlers, but other systems do. We need a way to set this in Emacs 23.2.

However, there seems to be a consensus that mailclient would be the right default on all systems now. Is this agreed?

Attachment: smime.p7s
Description: S/MIME cryptographic signature

reply via email to

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