Hello Thomas, Jean-Christophe,

Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:

>>> [...]
>>> Do you have a sense for how far back the AppleScript method will work?
>>> [...]
>> The application that is called in the applescript is called "Contacts".
>>
>> Before July 2012, when macos 10.8 was released, it was called "Address Book".
>>
>> So if the script wants to support machines with an OS older that 10.8
>> there will be a need to check the OS version and change the name of
>> the application that is called.
> [...]
> Alexander, I see you report an error if osascript is not present.  Can
> you add a separate check via AppleScript for whether "Contacts" (or
> failing that, "Address Book") is running and accessible?  Then the user
> would get a clear error if osascript can't access the application for
> whatever reason.

Thomas, thanks for pointing out the subtlety about the app naming which
I had happily ignored ;-). Luckily, Apple provide a
forward-compatibility-catchall in that when I do a `tell application
"Address Book"` on a current macOS, it will "translate" this and connect
to the right app (i.e. Contacts). This is of course to support legacy
scripts (hidden goodness). Therefore, we can simply use `tell
application "Address Book"`, and it will work on all 10.x macOS-es.

> Can you also use the AppleScript line continuation character (U+00AC,
> from what I can tell from some online searches) to wrap the longest line
> to under 80 columns?

I didn't know about U+00AC; cool. Done.

> [...]
> Alexander, given Jean-Christophe's research, and once the above
> AppleScript-related comments are sorted out, I think this is fine to go
> in, code-wise.

Agree. I have added both above suggestions ("Contacts" vs. "Address
Book", and U+00AC) to the attached, updated version. I have also amended
the diagnostic error message to be more specific about the problem
encountered. I have also folded the lengthy error message line to be
below the 80 limit. Not sure whether this would be considered good
practice?

> Would you be able to write a section in the EUDC manual describing the
> backend and how it relates to eudcb-mab.el?
>
> I don't think it hurts to offer both backends, provided they're
> documented and contrasted in the EUDC manual.

Yes, I'll be happy to write up a text for the manual. I agree that it
would be good to offer both backends for a transition period.

> [...]
> diff --git a/lisp/net/eudcb-macos-contacts.el b/lisp/net/eudcb-macos-contacts.el
> [...]

Thanks for these improvements. All applied in the attached, updated
version; except for the last one, which I solved differently.


Many thanks and looking forward to your thoughts,

  --alexander