Re: ns-do-applescript

[chad <yandros@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3407 bytes --]

Short, short version: imagine that Sun built a version of solaris that
almost entirely replaced "shell" with a variant of Java that didn't
*inititally* come with a stand-alone interpreter, but did add one later.
Then: s/Sun/Apple/, s/solaris/macosx/, and s/Java/AppleScript/.

Longer version:

Since Apple bundles together the user toolkit, system UI, "window manager",
and system services all behind a (sadly mostly proprietary) wall, native
macOS applications that want to do "plumbing" use a scripting language
called "Applescript", based very loosely around HyperCard. This dates back
to the previous millenium, to well before the Unix-like Mac OS X was built
from a combination of Mach, FreeBSD, and NextSTEP. In those days, there was
no multi-user OS underpinning that understood things like shell scripts and
forking processing. Applications that are "Applescript aware", which
includes basically everything that comes with the OS as well as much of the
3rd party software could be interacted with using "code" like "tell
application Music to play U2" or "tell application Mail to open new message
addressed to monopoly@microsoft.com" (as well as more complicated scripts
with variables, logic, etc).

At some point, Apple regularized the OS-level interface to this language,
and named it the "Open Scripting Architecture" -- presumably back when
adding the word "Open" to every kind of software was de rigueur. The ns
port of Emacs to macosx added the ability to use the system library calls
that tie applications into the OS-level infrastructure, known as "the
scripting system", "the scripting layer", or similar variants.

If memory serves, some time later macosx itself grew a unix-level cli for
this system itself, which is where "the osascript executable" came into
play, which allowed mixing between Applescript and other scripting
languages (I have seen both perl and tcl code that "automated" macosx by
generating AppleScript and feeding it to the system, probably via osascript
or a predecessor thereof). Before then, applications needed to link to the
built-in system scripting libraries and call the related functions.

In emacs, there are a few nice things that can be done by having Emacs ask
the OS to execute Applescript. Some of these, *in theory*, benefit from not
needing to fork an interpreter each time. In practice, macos these days
(note: I stopped using it regularly several years ago) has more or less
enough of a unix-like underpinning that people can mostly use the same sort
of inter-process techniques that they use on other operating systems. The
remaining areas of friction come from interacting with the system software;
for example, asking the default web browser the URL of its various windows.

From my point of view, this pretty clearly falls into the category of
native application support on a proprietary OS. It's not enabling anything
that doesn't already exist, by definition; but it is potentially making
life easier for Emacs users on that platform. In practice, there wasn't a
lot of upside when last I looked, so it probably doesn't warrant a lot of
effort to continue, but there are a few platform-standard things that it
enables that are useful and benefit from calling a library function rather
than forking an interpreter. Of course, that relies on there being someone
willing to maintain the glue to those library functions.

Hope that helps,
~Chad

[-- Attachment #2: Type: text/html, Size: 3820 bytes --]