I read the Emacs thread. Say what you want about the FSF as a whole, or even Emacs policy as a whole. But this is at another level. The proposal was to remov

I read the Emacs thread. Say what you want about the FSF as a whole, or even Emacs policy as a whole. But this is at another level. The proposal was to remove the function ns-do-applescript, which runs an AppleScript script using the C API, because AppleScript is proprietary and thus bad. I can sort of understand that. What I can't understand is the suggested replacement: to run the same AppleScript scripts using a shell command. And I don't mean something like "well, we won't endorse any use of AppleScript, but 'run shell command' is a general-purpose interface and we can't stop users from using it for AppleScript if they really want to". I could understand that. No, there are uses of AppleScript in Lisp code within the Emacs repo itself (not a separate package repository or something). The thread discussed one such use, which fetches the user's contact list using AppleScript. This was considered completely fine. Fetching the user's contact list, as a high-level feature, is supported on free operating systems, so it's okay to also implement it for non-free operating systems, even if that requires using a proprietary OS-specific API, in this case AppleScript. All fine. But for some reason, it was considered essential to do this using a shell command instead of a C API. There was even a post suggesting that ns-do-applescript be reimplemented on top of the shell command instead of the C API. In this case, Emacs would still be offering its users a built-in API to run AppleScript scripts, just… in Lisp code instead of C! Because that's so different!