From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: chad Newsgroups: gmane.emacs.devel Subject: Re: [Proposal] New EUDC backend for macOS address book Date: Mon, 27 Apr 2020 13:00:02 -0700 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000d15d7a05a44b2982" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="51618"; mail-complaints-to="usenet@ciao.gmane.io" Cc: EMACS development team To: Alexander Adolf Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 27 22:01:28 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jT9wW-000DJY-Jz for ged-emacs-devel@m.gmane-mx.org; Mon, 27 Apr 2020 22:01:28 +0200 Original-Received: from localhost ([::1]:60222 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jT9wV-0000dQ-JW for ged-emacs-devel@m.gmane-mx.org; Mon, 27 Apr 2020 16:01:27 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48466) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jT9vO-0007ky-QH for emacs-devel@gnu.org; Mon, 27 Apr 2020 16:00:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jT9vN-00029r-Pz for emacs-devel@gnu.org; Mon, 27 Apr 2020 16:00:18 -0400 Original-Received: from mail-yb1-xb2d.google.com ([2607:f8b0:4864:20::b2d]:44081) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jT9vN-00028F-D4 for emacs-devel@gnu.org; Mon, 27 Apr 2020 16:00:17 -0400 Original-Received: by mail-yb1-xb2d.google.com with SMTP id o139so10115707ybc.11 for ; Mon, 27 Apr 2020 13:00:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=io+igjJQwfVfPRRNwbQqmeaFmXpMtyOuXtphSsxqQLA=; b=Xp68nwYFE2kloMW1nuXiNjAGPxwJ/ugslGYVdDPV0/gX/X2+fDia6FSWxgWQveAKK2 3xFsjS30HKcMCYeG/e/0qlxd0S330rL3+bF522YEQZIoWIU9ottj6Owc8lqM86xQaOgH S/bKj85VeRArN9L11N2yAigbp3t6ZePa7dXwxmuV23XEzF/nGuaau2ZX8rD45Vv5cYuk i9kTna8nmphi0YKQo1xDUHyzg63JGf1sejVWXqgf3lvnTCXVL5gKZ54HrebvzTFcB6wl mmr3yKVxpfVBbXS6HoTl3zStF8Wpn8skDeDqFoEde1qNJsJ4UhQNuyg9LOpnYNi1trck HJhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=io+igjJQwfVfPRRNwbQqmeaFmXpMtyOuXtphSsxqQLA=; b=RpnDPZde/Qxkxb0JWNuNqfCe6jwc0giqHbh6TY/zz88BtCY78sJ0oetfLEkZ9UAK7N ncCeL3XTrWvnoAvchGInBs6VJCgoMoTang1S+nhig93FQM79bJsmYMLNGZrOotE6pByL kqXo2UnTIeUoi1cGz9J+Nz0qaaK+Q4/OFIznwgT8IenkgW0GCvUEGioNDe16GiYfd7gw pg+sIeKmGDQYtMWdZFCGboV8i0NGJCkYPuP/LwvTwpaftuFrigFacB93cIn3hM2DXPbA DFmXq6qWVWQLXlT0d12zx+PUZKUYQiaKviKpxlM0of5wXxEvzKkt+CDMQQqFbmMFOeu4 aQkQ== X-Gm-Message-State: AGi0Pub0fWdP7pVh7vaZ3V2Zt5i15tuaQArjRYTZ0RK7/9vK8cZkRad2 vsuCHzuh31ybJ14lV1KPkxjeoeQVQ9WR6BgOuj+5Vg== X-Google-Smtp-Source: APiQypJWsiSaLNoKvWWuQrtu6LPXqawGVplPKLZMHctEwolcwgqHwVqYkcNfPBFGh4CJXx7yToQJZGhckH5YIANzasc= X-Received: by 2002:a25:e008:: with SMTP id x8mr8480789ybg.295.1588017614641; Mon, 27 Apr 2020 13:00:14 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::b2d; envelope-from=yandros@gmail.com; helo=mail-yb1-xb2d.google.com X-detected-operating-system: by eggs.gnu.org: Error: [-] PROGRAM ABORT : Malformed IPv6 address (bad octet value). Location : parse_addr6(), p0f-client.c:67 X-Received-From: 2607:f8b0:4864:20::b2d X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:247960 Archived-At: --000000000000d15d7a05a44b2982 Content-Type: text/plain; charset="UTF-8" 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 < alexander.adolf@condition-alpha.com> 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 > > --000000000000d15d7a05a44b2982 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 osascri= pt, did you find the performance acceptable for interactive work?

<= /div>
Separately, over my years in (what's now) macOS, I found that= Apple would periodically update its file names, but rarely break file-leve= l compatability=C2=A0in significant ways, so it might be sufficient for eud= cb-mab.el=C2=A0to look through a short list of paths for the most recent ex= istant=C2=A0file. I had a (pretty simple) script that used Mail.app's S= QLite files that did this over ~5 versions, and never had any trouble with = it.

Hope that helps,
~Chad
=C2= =A0

On Mon, Apr 27, 2020 at 8:11 AM Alexander Adolf <alexander.adolf@condition-alpha.co= m> 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/archi= ve/documentation/AppleScript/Conceptual/AppleScriptLangGuide/introduction/A= SLR_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<= br> 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 th= e
Apple library code it builds upon. I hence decided to instead use
`call-process()' to invoke the osascript [4] command line utility, whic= h
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=3D39890
[4] https://ss64.com/osx/osascript.html


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

=C2=A0 --alexander

--000000000000d15d7a05a44b2982--