bug#3963: 23.0.94; Emacs on nextstep/Mac OS X should handle mailto: URLs

bug#3963: 23.0.94; Emacs on nextstep/Mac OS X should handle mailto: URLs

[Teemu Likonen]

On 2009-07-29 13:38 (-0500), Harald Hanche-Olsen wrote:

> Now click on a mailto: link in your favourite web browser, or else run
> a command like this:  open mailto:nobody@example.com
>
> Notice that Emacs comes to the foreground, but nothing more happens.
> What SHOULD happen is that Emacs opens a new draft email message
> addressed to the named recipient.

As you noticed, currently Emacs doesn't handle mailto URLs. Here's my
solution for the issue:

http://www.emacswiki.org/emacs/MailtoHandler

bug#3963: 23.0.94; Emacs on nextstep/Mac OS X should handle mailto: URLs

[Leo]

On 2009-07-29 20:05 +0100, Teemu Likonen wrote:
> On 2009-07-29 13:38 (-0500), Harald Hanche-Olsen wrote:
>
>> Now click on a mailto: link in your favourite web browser, or else run
>> a command like this:  open mailto:nobody@example.com
>>
>> Notice that Emacs comes to the foreground, but nothing more happens.
>> What SHOULD happen is that Emacs opens a new draft email message
>> addressed to the named recipient.
>
> As you noticed, currently Emacs doesn't handle mailto URLs. Here's my
> solution for the issue:
>
> http://www.emacswiki.org/emacs/MailtoHandler

There are already a few functions to handle mailto in Emacs for example
url-mailto.

-- 
Leo's Emacs uptime: 49 days, 5 hours, 48 minutes, 40 seconds

bug#3963: 23.0.94; Emacs on nextstep/Mac OS X should handle mailto: URLs

[Teemu Likonen]

On 2009-07-29 20:29 (+0100), Leo wrote:

>> http://www.emacswiki.org/emacs/MailtoHandler
>
> There are already a few functions to handle mailto in Emacs for
> example url-mailto.

I have tried that but didn't manage to make it do anything useful. It
requires RFC2368 decoding, then splitting URLs fields, then RFC2047
decoding. URL-MAILTO does not seem to do those. Here's a test URL:

mailto:test@invalid?subject=%3d%3fUTF-8%3fB%3fVGVzdGluZyDigJ1zdHVmZuKAnQo%3d%3f%3d&cc=test2@invalid

bug#3963: 23.0.94; Emacs on nextstep/Mac OS X should handle mailto: URLs

[Leo]

On 2009-07-29 20:46 +0100, Teemu Likonen wrote:
> On 2009-07-29 20:29 (+0100), Leo wrote:
>
>>> http://www.emacswiki.org/emacs/MailtoHandler
>>
>> There are already a few functions to handle mailto in Emacs for
>> example url-mailto.
>
> I have tried that but didn't manage to make it do anything useful. It
> requires RFC2368 decoding, then splitting URLs fields, then RFC2047
> decoding. URL-MAILTO does not seem to do those. Here's a test URL:
>
> mailto:test@invalid?subject=%3d%3fUTF-8%3fB%3fVGVzdGluZyDigJ1zdHVmZuKAnQo%3d%3f%3d&cc=test2@invalid

Maybe a patch could be proposed to Emacs?

-- 
Leo's Emacs uptime: 49 days, 7 hours, 8 minutes, 27 seconds

bug#3963: 23.0.94; Emacs on nextstep/Mac OS X should handle mailto: URLs

[Harald Hanche-Olsen]

+ Teemu Likonen <tlikonen@iki.fi>:

> As you noticed, currently Emacs doesn't handle mailto URLs. Here's my
> solution for the issue:
> 
> http://www.emacswiki.org/emacs/MailtoHandler

But that requires the use of emacsclient. How do you talk firefox,
safari, camino, opera, and vienna into running emacsclient in response
to a user clicking on a mailto: link? The first issue is for emacs to
actually receive the incoming message requesting the handling of the
mailto: url. I don't know how that can be accomplished, but note that
emacs already responds correctly to "open -a emacs filename". I assume
the basic messaging mechanism must be the same?

- Harald

bug#3963: 23.0.94; Emacs on nextstep/Mac OS X should handle mailto: URLs

[Teemu Likonen]

On 2009-07-29 15:38 (-0500), Harald Hanche-Olsen wrote:

> + Teemu Likonen <tlikonen@iki.fi>:
>
>> As you noticed, currently Emacs doesn't handle mailto URLs. Here's my
>> solution for the issue:
>> 
>> http://www.emacswiki.org/emacs/MailtoHandler
>
> But that requires the use of emacsclient. How do you talk firefox,
> safari, camino, opera, and vienna into running emacsclient in response
> to a user clicking on a mailto: link? The first issue is for emacs to
> actually receive the incoming message requesting the handling of the
> mailto: url. I don't know how that can be accomplished, but note that
> emacs already responds correctly to "open -a emacs filename". I assume
> the basic messaging mechanism must be the same?

I does not require emacsclient. The regular emacs executable has --eval
option too. On that web page there's a shell script. The idea is to
configure it to be the mail client program. It passes the mailto URL to
emacs which then does the rest using the elisp function which was also
on that web page. For example, I have configured my Firefox and my KDE
desktop environment to use that shell script as mail client program.
Works nicely.

Obviously I'd agree that it's better if Emacs did all this automatically
but so far the solution on that web page is probably the easiest and
technically least intrusive -- and uses existing Emacs features as much
as possible.

The url-mailto function which Leo mentioned tries to do many things
manually. It's unnecessary because there's already
rfc2368-parse-mailto-url for splitting the email fields in URLs.

bug#3963: 23.0.94; Emacs on nextstep/Mac OS X should handle mailto: URLs

[Harald Hanche-Olsen]

+ Teemu Likonen <tlikonen@iki.fi>:

> I does not require emacsclient. The regular emacs executable has --eval
> option too. On that web page there's a shell script. The idea is to
> configure it to be the mail client program.

But firefox, on the mac, cannot be configured to use an arbitrary
program or shell script as the mail client. It wants a full-blown Mac
application, which it can activate and then send an Apple event to.
Or have I misunderstood something?

> For example, I have configured my Firefox and my KDE
> desktop environment to use that shell script as mail client program.
> Works nicely.

But I am not talking about KDE. I am talking about Mac OS X and its
native GUI.

Now I have been wasting time digging around in ns-win.el and
term/nsterm.m to try to figure out how all this works, but I am not
familiar with OS X internals nor can I read Objective C, so it all
makes my head spin.

But I can figure out some bits: If I run open -a emacs FILENAME in a
terminal, this apparently results in an event handled by [NXapp run]
and gets transferred into an <ns-open-file-line> event which is
handled by the usual emacs event loop. Similarly, if I use the service
menu in another app to ask emacs to do something, a
<ns-spi-service-call> event results. But run open -a emacs
mailto:foo@example.com, and no such translation happens.

- Harald

bug#3963: 23.0.94; Emacs on nextstep/Mac OS X should handle mailto: URLs

[Harald Hanche-Olsen]

In Mail.app on Mac OS X, open Preferences -> General, and select Emacs
as the the default email reader.
Quit Mail.app and never use it again. 8-)

Now click on a mailto: link in your favourite web browser, or else run
a command like this:  open mailto:nobody@example.com

Notice that Emacs comes to the foreground, but nothing more happens.
What SHOULD happen is that Emacs opens a new draft email message
addressed to the named recipient.

Note that the nextstep port is already capable of similar feats, using
the Service menu in any application; but this is more important, as
users click on mailto links all the time, and we don't want to
discourage their use of Emacs for email.


In GNU Emacs 23.0.94.1 (i386-apple-darwin9.7.1, NS apple-appkit-949.46)
 of 2009-06-17 on mach.local
Windowing system distributor `Apple', version 10.3.949
configured using `configure  '--with-ns''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  value of $XMODIFIERS: nil
  locale-coding-system: nil
  default-enable-multibyte-characters: t