ns-do-applescript

ns-do-applescript

[Po Lu]

Why does Emacs have support for running AppleScript programs?
Even worse, that support is only available on Mac OS.

Re: ns-do-applescript

[Filipp Gunbin]

On 23/05/2022 20:14 +0800, Po Lu wrote:

> Why does Emacs have support for running AppleScript programs?
> Even worse, that support is only available on Mac OS.

Just FTR, AppleScript is used in eudcb-macos-contacts.el, but via
osascript executable.

Filipp

Re: ns-do-applescript

[Po Lu]

Filipp Gunbin <fgunbin@fastmail.fm> writes:

> Just FTR, AppleScript is used in eudcb-macos-contacts.el, but via
> osascript executable.

Indeed, which is why I further fail to see the point of making that a
builtin.

IMHO Emacs should not integrate the ability to run a language with a
proprietary runtime that is only available on a proprietary operating
system.  Which is completely out of scope of a GUI port (the NS port.)

Does anyone object to its removal? It would also resolve bug#39890 and
other problems stemming from our maintenance of this misfeature, and
people can use `osascript' in a subprocess anyway.

Re: ns-do-applescript

[Daniel Martín]

Po Lu <luangruo@yahoo.com> writes:

> Does anyone object to its removal? It would also resolve bug#39890 and
> other problems stemming from our maintenance of this misfeature, and
> people can use `osascript' in a subprocess anyway.

I don't object delegating to osascript as a subprocess, but there are
probably lots of packages and user customizations already calling
ns-do-applescript.  We should deprecate the API before removing it, and
the deprecation message should tell people how they can call osascript
in an equivalent way.

Re: ns-do-applescript

[Stefan Monnier]

Daniel Martín [2022-05-24 22:00:12] wrote:
> I don't object delegating to osascript as a subprocess, but there are
> probably lots of packages and user customizations already calling
> ns-do-applescript.  We should deprecate the API before removing it, and
> the deprecation message should tell people how they can call osascript
> in an equivalent way.

Can we re-implement `ns-do-applescript` as an ELisp function that runs
`osascript`?


        Stefan

ns-do-applescript

[Jon Snader]

I don't understand the urgent—or, indeed, any—need to eliminate 
this call. I've been using it for years to populate an Emacs 
buffer with the URL of the current page displayed in Safari. I 
used to use osascript as recommended by those advocating 
ns-do-applescript's removal but moved to ns-do-applescript when 
osascript became unacceptably slow. That issue may have been 
resolved but I've never felt the need to revisit the matter.

According the the 2020 Emacs survey, Mac users represent 26.6% of 
Emacs users (https://emacssurvey.org/2020/) so it's hardly a niche 
environment for Emacs. As macOS is the second largest user base, I 
don't see how it hurts to make Mac users' life marginally easier.

Re: ns-do-applescript

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Just FTR, AppleScript is used in eudcb-macos-contacts.el, but via
  > osascript executable.

The comments in that file suggest that this is not a general facility
to execute AppleScript programs, but rather a way to get data out of a
MacOS-specific contacts database.

Am I right about that?

Other systems will have other kinds of contacts databases doing the
same job, and Emacs seems to support them just as well or better.

Am I right about that?

If so, then under the conditions in the node Non-GNU-Only Features of
the GNU Maintainers Guide, this is a system-specific implementation of
a feature that is supported equally well on the GNU system, so it is
ok.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: ns-do-applescript

[Filipp Gunbin]

On 24/05/2022 17:26 -0400, Richard Stallman wrote:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > Just FTR, AppleScript is used in eudcb-macos-contacts.el, but via
>   > osascript executable.
>
> The comments in that file suggest that this is not a general facility
> to execute AppleScript programs, but rather a way to get data out of a
> MacOS-specific contacts database.
>
> Am I right about that?

Yes.

> Other systems will have other kinds of contacts databases doing the
> same job, and Emacs seems to support them just as well or better.
>
> Am I right about that?

eudcb-macos-contacts is an EUDC backend.  Other backends in Emacs are
mainly eudcb-ldap and eudcb-bbdb, they both work on GNU system (but on
nonfree systems as well), and are more complete than
eudcb-macos-contacts.

> If so, then under the conditions in the node Non-GNU-Only Features of
> the GNU Maintainers Guide, this is a system-specific implementation of
> a feature that is supported equally well on the GNU system, so it is
> ok.

Yes, but the topic was about the C function, ns-do-applescript, not
about eudcb-macos-contacts...

Filipp

Re: ns-do-applescript

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> The comments in that file suggest that this is not a general facility
> to execute AppleScript programs, but rather a way to get data out of a
> MacOS-specific contacts database.
>
> Am I right about that?

Yes.  But I don't see why that cannot call osascript in a subprocess
either, since what the Emacs C code provides is a general facility for
evaluating arbitrary AppleScript code, which is not present on any free
system.

Re: ns-do-applescript

[Po Lu]

Jon Snader <jcs@irreal.org> writes:

> I don't understand the urgent—or, indeed, any—need to eliminate this
> call. I've been using it for years to populate an Emacs buffer with
> the URL of the current page displayed in Safari. I used to use
> osascript as recommended by those advocating ns-do-applescript's
> removal but moved to ns-do-applescript when osascript became
> unacceptably slow. That issue may have been resolved but I've never
> felt the need to revisit the matter.
>
> According the the 2020 Emacs survey, Mac users represent 26.6% of
> Emacs users (https://emacssurvey.org/2020/) so it's hardly a niche
> environment for Emacs. As macOS is the second largest user base, I
> don't see how it hurts to make Mac users' life marginally easier.

macOS is a proprietary operating system.  We don't try to make its users
lives easier, we try to encourage them switch to GNU/Linux.  Supporting
a feature that is only available there would just encourage users to use
it.

Not to mention that the AppleScript support has several bugs, including
bug#39890, that I cannot fix or easily test, since AppleScript is not
available in GNUstep.

Re: ns-do-applescript

[Tim Cross]

Po Lu <luangruo@yahoo.com> writes:

> Jon Snader <jcs@irreal.org> writes:
>
>> I don't understand the urgent—or, indeed, any—need to eliminate this
>> call. I've been using it for years to populate an Emacs buffer with
>> the URL of the current page displayed in Safari. I used to use
>> osascript as recommended by those advocating ns-do-applescript's
>> removal but moved to ns-do-applescript when osascript became
>> unacceptably slow. That issue may have been resolved but I've never
>> felt the need to revisit the matter.
>>
>> According the the 2020 Emacs survey, Mac users represent 26.6% of
>> Emacs users (https://emacssurvey.org/2020/) so it's hardly a niche
>> environment for Emacs. As macOS is the second largest user base, I
>> don't see how it hurts to make Mac users' life marginally easier.
>
> macOS is a proprietary operating system.  We don't try to make its users
> lives easier, we try to encourage them switch to GNU/Linux.  Supporting
> a feature that is only available there would just encourage users to use
> it.
>

This might be a reaonable argument when considering adding additional
support/integration, but falls short when referencing work which ahs
already been completed and has been part of Emacs for some time. 

> Not to mention that the AppleScript support has several bugs, including
> bug#39890, that I cannot fix or easily test, since AppleScript is not
> available in GNUstep.

Perhaps then your not the right person to address those bugs? Perhaps
they need to be addressed by someone who does actually use that
platform? 

The argument that leaving such functionality in place will encourage
users to use it seems somethwat flawed. This functionality is only
available if your running on that platform and if your already running
on that platform, encouragement to run on that platform doesn't amount
to much. I would also suggest far more enrouagement comes from having
support to build Emacs on that platform in the first place. 

It is also possible that having this support means users can actually
use Emacs to perform some tasks which would otherwise require closed
proprietary solutions or which would be easier to do with close
properietary solutions. Maybe this support actually enrouages users to
use Emacs instead of a non-free editor which has applescript support?
 

Re: ns-do-applescript

[Po Lu]

Tim Cross <theophilusx@gmail.com> writes:

> This might be a reaonable argument when considering adding additional
> support/integration, but falls short when referencing work which ahs
> already been completed and has been part of Emacs for some time. 

If such a feature lands by mistake, our policy is to remove it until it
is also available on a free system.  That has happened many times, most
recently with "tabbed windows" and color fonts on macOS.

> Perhaps then your not the right person to address those bugs? Perhaps
> they need to be addressed by someone who does actually use that
> platform? 

Unfortunately, the "someone who does actually use that platform"
recently quit.

> The argument that leaving such functionality in place will encourage
> users to use it seems somethwat flawed. This functionality is only
> available if your running on that platform and if your already running
> on that platform, encouragement to run on that platform doesn't amount
> to much. I would also suggest far more enrouagement comes from having
> support to build Emacs on that platform in the first place. 
>
> It is also possible that having this support means users can actually
> use Emacs to perform some tasks which would otherwise require closed
> proprietary solutions or which would be easier to do with close
> properietary solutions. Maybe this support actually enrouages users to
> use Emacs instead of a non-free editor which has applescript support?

That horse is already dead, and this is neither the place nor the time
to beat it.

Re: ns-do-applescript

[Filipp Gunbin]

On 25/05/2022 12:46 +0800, Po Lu wrote:

> Tim Cross <theophilusx@gmail.com> writes:
>
>> This might be a reaonable argument when considering adding additional
>> support/integration, but falls short when referencing work which ahs
>> already been completed and has been part of Emacs for some time. 
>
> If such a feature lands by mistake, our policy is to remove it until it
> is also available on a free system.  That has happened many times, most
> recently with "tabbed windows" and color fonts on macOS.

But here it's not a user-level editor feature, it's an API for
interoperability with host OS.

Re: ns-do-applescript

[Pankaj Jangid]

Po Lu <luangruo@yahoo.com> writes:

> If such a feature lands by mistake, our policy is to remove it until it
> is also available on a free system.  That has happened many times, most
> recently with "tabbed windows" and color fonts on macOS.

There is one more feature that is available on MacOS but not available
for GNU/Linux users.

The feature is EUDC’s support for Mac OS’s address book. Other backends
supported by EUDC are - bbdb and LDAP. bbdb is Emacs specific address
book but it is not shipped with Emacs and LDAP is too much of a
configuration for a Desktop user.

Re: ns-do-applescript

[Alexander Adolf]

Hello,

this is the author of eudcb-macos-contacts chiming in. I would not have
any objections to a well managed deprecation, and later removal of the
ns-do-applescript elisp API. The semantics of that API, and the
command-line replacement osascript are very similar: provide the script
in a string, feed that to the API or process, and then handle whatever
that returns. I do hence think making the change should be a
straightforward exercise for any package author.

One aspect that has not been touched on in this thread is performance.
Starting an external process will typically be more expensive than
calling a C API, and thus there could be a noticeable performance
penalty for small scripts which are called often. But that's not the
case for eudcb-macos-contacts.


Hoping to have helped,

  --alexander

Re: ns-do-applescript

[Howard Melman]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Daniel Martín [2022-05-24 22:00:12] wrote:
>> I don't object delegating to osascript as a subprocess, but there are
>> probably lots of packages and user customizations already calling
>> ns-do-applescript.  We should deprecate the API before removing it, and
>> the deprecation message should tell people how they can call osascript
>> in an equivalent way.
>
> Can we re-implement `ns-do-applescript` as an ELisp function that runs
> `osascript`?

I do use it for simple interaction with the Finder and Safari such as:

    (do-applescript "tell application \"Safari\" to get the name of window 1")
    (do-applescript "tell application \"Safari\" to get the URL of document 1")

Part of the value of do-applescript is that it returns the
output as a string.  Quickly playing with call-process and
osascript isn't quite as trivial but I'm sure is doable.

-- 

Howard

Re: ns-do-applescript

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Does anyone object to its removal?

In principle, it is good to remove it, but there is no principled reason
why we must remove it, if that means breaking a user-level feature
that does work on non-MacOS systems.

It is good to look for alternative wasy to implement those features
on MacOS.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: ns-do-applescript

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I do use it for simple interaction with the Finder and Safari such as:

  >     (do-applescript "tell application \"Safari\" to get the name of window 1")
  >     (do-applescript "tell application \"Safari\" to get the URL of document 1")

Is it possible to do this with call-process
or by running a shell command?


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: ns-do-applescript

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> In principle, it is good to remove it, but there is no principled reason
> why we must remove it, if that means breaking a user-level feature
> that does work on non-MacOS systems.
>
> It is good to look for alternative wasy to implement those features
> on MacOS.

It should be easy to use the `osascript' binary instead.

Re: ns-do-applescript

[Howard Melman]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > I do use it for simple interaction with the Finder and Safari such as:
>
>   >     (do-applescript "tell application \"Safari\" to get the name of window 1")
>   >     (do-applescript "tell application \"Safari\" to get the URL of document 1")
>
> Is it possible to do this with call-process
> or by running a shell command?

I think so, though I have to figure out the right
incantation to get stdout returned as a string.  I might be
nice if call-process' DESTINATION arg had an option for this.

-- 

Howard

Re: ns-do-applescript

[Howard Melman]

Pedro Andres Aranda Gutierrez <paaguti@gmail.com> writes:

>> Can we re-implement `ns-do-applescript` as an ELisp function that runs
>> `osascript`?
>
> you mean something like:
> ;; (ns-do-applescript "tell application \"Emacs\" to activate"))
>  (call-process "osascript" nil nil nil "-e" "tell application \"Emacs\" to activate")
>
> Isn't it easier to explain than to actually write a function? ;-)

And the return value that ns-do-applescript handles?

-- 

Howard

Re: ns-do-applescript

[Andreas Schwab]

On Mai 26 2022, Howard Melman wrote:

> I think so, though I have to figure out the right
> incantation to get stdout returned as a string.  I might be
> nice if call-process' DESTINATION arg had an option for this.

See shell-command-to-string for how to do that.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: ns-do-applescript

[Howard Melman]

On May 26, 2022, at 10:17 AM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> 
> On Mai 26 2022, Howard Melman wrote:
> 
>> I think so, though I have to figure out the right
>> incantation to get stdout returned as a string.  I might be
>> nice if call-process' DESTINATION arg had an option for this.
> 
> See shell-command-to-string for how to do that.

More useful would be a pointer to an example using call-process.

Howard

Re: ns-do-applescript

[Stefan Monnier]

> Isn't it easier to explain than to actually write a function? ;-)

I thought it was obvious that my question was in relation to avoid
breaking compatibility with potential user code out there.


        Stefan

Re: ns-do-applescript

[Andreas Schwab]

On Mai 26 2022, Howard Melman wrote:

> On May 26, 2022, at 10:17 AM, Andreas Schwab <schwab@linux-m68k.org> wrote:
>> 
>> On Mai 26 2022, Howard Melman wrote:
>> 
>>> I think so, though I have to figure out the right
>>> incantation to get stdout returned as a string.  I might be
>>> nice if call-process' DESTINATION arg had an option for this.
>> 
>> See shell-command-to-string for how to do that.
>
> More useful would be a pointer to an example using call-process.

That's what shell-command is using, with the same meaning for the output
buffer.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: ns-do-applescript

[Pedro Andres Aranda Gutierrez]

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

You are absolutely right...  maybe I was reading too fast :-) ... and
egocentric
in the sense that yes I used it, but hey I could live without
ns-do-applescript.
You are right in that there may be code out there which may benefit from
and an elisp implementation...

Best, /PA

On Thu, 26 May 2022 at 17:07, Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> > Isn't it easier to explain than to actually write a function? ;-)
>
> I thought it was obvious that my question was in relation to avoid
> breaking compatibility with potential user code out there.
>
>
>         Stefan
>
>

-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

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

Re: ns-do-applescript

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > It should be easy to use the `osascript' binary instead.

I have never heard of "osascript".  What is that?  What systems
support it?  Does it exist on GNU/Linux?

Basically, what are the differences that make it better to use
osascript than applescript?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: ns-do-applescript

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> I have never heard of "osascript".  What is that?  What systems
> support it?  Does it exist on GNU/Linux?

It's only present in macOS.

> Basically, what are the differences that make it better to use
> osascript than applescript?

I think that binary _is_ Apple's proprietary AppleScript interpreter,
but using it in a subprocess to retrieve only contacts data (which is
already possible on free systems) must be more acceptable than Emacs
including a C primitive to do the same thing.

Re: ns-do-applescript

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Basically, what are the differences that make it better to use
  > > osascript than applescript?

  > I think that binary _is_ Apple's proprietary AppleScript interpreter,

If that is so, what is the significant difference between invoking
osascript and invoking applescript?  Those of us who don't use MacOS
know nothing about this.

  > but using it in a subprocess to retrieve only contacts data (which is
  > already possible on free systems) must be more acceptable than Emacs
  > including a C primitive to do the same thing.

Not necessarily -- it depends on facts that haven't been stated here.
Maybe a C primitive is better, but that depends on what exactly
the C primitive can do.

Since retrieving contact data in Emacs is supported on free systems,
adding code to do the same job on MacOS is ok in principle.  An
implementation which implements only that particular feature poses no
special problem.  Implementing something more general than that might
pose a problem.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: ns-do-applescript

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> If that is so, what is the significant difference between invoking
> osascript and invoking applescript?  Those of us who don't use MacOS
> know nothing about this.

osascript isn't linked into Emacs.

>   > but using it in a subprocess to retrieve only contacts data (which is
>   > already possible on free systems) must be more acceptable than Emacs
>   > including a C primitive to do the same thing.
>
> Not necessarily -- it depends on facts that haven't been stated here.
> Maybe a C primitive is better, but that depends on what exactly
> the C primitive can do.
>
> Since retrieving contact data in Emacs is supported on free systems,
> adding code to do the same job on MacOS is ok in principle.  An
> implementation which implements only that particular feature poses no
> special problem.  Implementing something more general than that might
> pose a problem.

The C primitive allows evaluating arbitrary AppleScript code, not just
extracting contacts data.

Re: ns-do-applescript

[chad]

[-- 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 --]

Re: ns-do-applescript

[Stefan Monnier]

> <flagelante>
> Yes, I repent, I confess... I use Emacs on a macOS...
> </flagelante>

I know this discussion sounds like some of us want to punish macOS users
for their sins, but that's not what this is about.  From the FSF's point
of view, using a proprietary system like Windows or macOS is causing
self-harm rather than harm to others (to some extent it might also harm
others because of the network effect, but that's a secondary concern).


        Stefan

Re: ns-do-applescript

[Po Lu]

chad <yandros@gmail.com> writes:

> 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.

From my POV, it is easily replaced by running `osascript' in a
subprocess, and the features provided by the so-called "native
application support" are not available on free operating systems.  It
also comes with various disadvantages, such as quitting being disabled
while the script is running, which isn't the case inside subprocesses.

Re: ns-do-applescript

[Stefan Monnier]

> From my POV, it is easily replaced by running `osascript' in a
> subprocess,

Is it?


        Stefan "who asked already but hasn't seen an answer yet"

Re: ns-do-applescript

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > 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/.

Sorry, I can't follow that.  I know nothing about Applescript except 
what little I've learned from this conversation.

I'd rather not learn enough about Applescript to be able to judge
whether using it is ok.  I hope that others will understand our
general criteria, and the specific facts of these issues, enough
to be able to make a thoughtful decision about them.

One possible approach would be to delete the Lisp-level interface to
run Appescript code, and add C-level support for doing certain
system-independent tasks by invoking Applescript.  I am not saying
that is the one and only right approach, or that it is the best
approach.  Only that it is one more to consider.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)