[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Proposal] New EUDC backend for macOS address book
From: |
Alexander Adolf |
Subject: |
Re: [Proposal] New EUDC backend for macOS address book |
Date: |
Tue, 05 May 2020 15:30:14 +0200 |
Hello Chad,
Many thanks for your swift response, constructive comments, and
apologies for the delay in getting back to you.
chad <address@hidden> writes:
> 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?
Either way, via do_applescript(), or via the osascript CLI utility,
AppleScript is slow. Hence, the additional burden of spawning the new
process for the CLI utility does not introduce a noticeable difference
to my experience.
In that light, I wouldn't suggest to configure this as part of a
completion mechanism that pops up while typing (such as e.g. company
mode), but to bind it to some key chord. Ultimately, you will likely
only want to use it in very specific contexts (e.g. message header)
anyway.
> 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.
> [...]
I had published a plugin for the mail app that ships with macOS
[1][2]. This also used an undocumented interface; so I know what you're
talking about. The point for going the reverse engineering route was
that it was the only way at the time. After each macOS release, there
was a gap of a few weeks, since I had to reverse engineer what Apple had
changed, fix my code, and then keep using it for a while to be sure the
new version would work reliably enough to expose it to the general
public.
You're right in that Apple, as we all, usually make incremental changes
only. But it remains a question of sheer luck, whether the next new
version from Apple will break things beyond repair.
Hence, my baseline is, if there's a documented interface for the
purpose, look no further.
[1] https://www.condition-alpha.com/blog/?p=1741
[2]
https://www.condition-alpha.com/software/composeit-manual/en.lproj/ComposeIT.html
Many thanks and cheers,
--alexander