emacs-devel
[Top][All Lists]
Advanced

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

Re: [Proposal] New EUDC backend for macOS address book


From: chad
Subject: Re: [Proposal] New EUDC backend for macOS address book
Date: Mon, 27 Apr 2020 13:00:02 -0700

It's been a while since I tried it myself (my macbook pro finally died early last year), but when I last tried it, going through applescript was quite slow. In your experience with shelling out to osascript, did you find the performance acceptable for interactive work?

Separately, over my years in (what's now) macOS, I found that Apple would periodically update its file names, but rarely break file-level compatability in significant ways, so it might be sufficient for eudcb-mab.el to look through a short list of paths for the most recent existant file. I had a (pretty simple) script that used Mail.app's SQLite files that did this over ~5 versions, and never had any trouble with it.

Hope that helps,
~Chad
 

On Mon, Apr 27, 2020 at 8:11 AM Alexander Adolf <address@hidden> wrote:
Dear Emacs Developers,

I am in the process of migrating my email workflow to `notmuch-mode'
within Emacs. While `notmuch-mode' provides a completion backend for
`company-mode' to get auto-completion for email addresses from your
notmuch email archive, I was looking for a way to give me
auto-completion for email addresses from my macOS address book, too.

My research lead me to EUDC [1], and its `eudcb-mab.el', but which
didn't work out of the box for me. Looking at the code, it turns out
that `eudcb-mab.el' accesses the SQLite file used by macOS address book
to store a local copy of the contacts, and reverse-engineers its
contents. This is however not documented by Apple as an "official" way
of accessing that data, and in fact Apple had recently changed the file
name of the SQLite. This broke `eudcb-mab.el' for me, as it was still
looking for the old file name. Also, since it is an undocumented file,
Apple may choose to not only change the file name, but also its inner
structure at any point.

[1] https://www.gnu.org/software/emacs/manual/html_mono/eudc.html

On the other hand, there is an Apple officially documented, and endorsed
way of accessing the macOS address book contacts, and this is via
AppleScript [2]. Being a published and documented API, it can probably
be expected to remain stable, and invariant towards any redesigns of the
macOS address book app that Apple may choose to undertake in the
foreseeable future.

[2] https://developer.apple.com/library/archive/documentation/AppleScript/Conceptual/AppleScriptLangGuide/introduction/ASLR_intro.html

I hence set out to write a new backend for EUDC to get access to macOS
address book contacts via AppleScript. The result is
`eudcb-macos-contacts.el', which is enclosed with this message, and
which I would kindly like to propose for inclusion as part of EUDC (and
replacing the existing `eudcb-mab.el').

Yes, I have duly signed the copyright assignment (rt.gnu.org #1503473).

In my implementation, I found that - interestingly - there is an elisp
function in Emacs core, cunningly called `do_applescript()', and which
is intended to execute AppleScript on the macOS platform from within
Emacs. Unfortunately, I did find some oddities with it (see debbugs
#39890 [3]), but couldn't discern whether the cause was in
`do_applescript()' itself (so a fix could have been proposed), or in the
Apple library code it builds upon. I hence decided to instead use
`call-process()' to invoke the osascript [4] command line utility, which
ships as part of every macOS. This does work reliably for me, and yields
a more graceful overall behaviour of Emacs during large queries (again
see debbugs #39890 [3]).

[3] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39890
[4] https://ss64.com/osx/osascript.html


Many thanks in advance for your considerations, and looking forward to
your thoughts,

  --alexander


reply via email to

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