occasional “Applescript error 1” when switching modes

[sellout]

When I googled for this error, #13 was the first of very few results, but that is closed, and I feel like I have some more context and some suggestions.

This doesn’t happen to me on startup (as it seemed to in #13), regardless of whether the system is dark or light when I start Emacs. It also doesn’t happen on every timer firing¹. Even when the mode changes, it only happens sometimes, and can happen switching in either direction (dark ↔ light). When it happens, debugger-continue causes the mode to change as expected.

Perhaps the reason it appears to succeed is that it actually doesn’t succeed, but by the time I debugger-continue, the timer has fired again successfully, and the change was merely blocked by the debugger state?

Backtrace

Debugger entered--Lisp error: (error "AppleScript error 1")
  auto-dark--is-dark-mode-ns()
    debugger-may-continue = t
    inhibit-redisplay = nil
    inhibit-debugger = t
    inhibit-changing-match-data = nil
  auto-dark--is-dark-mode-applescript()
  auto-dark--is-dark-mode()
  auto-dark--check-and-set-dark-mode()
  apply(auto-dark--check-and-set-dark-mode nil)
  timer-event-handler([t 26256 59208 207654 5 auto-dark--check-and-set-dark-mode nil nil 0 nil])
    inhibit-quit = t

additional debugging info

In GNU Emacs 29.3 (build 1, aarch64-apple-darwin23.4.0, NS appkit-2487.50
Version 14.4.1 (Build 23E224))
Windowing system distributor 'Apple', version 10.3.2487
System Description:  macOS 14.5

Configured using:
 'configure --prefix=/nix/store/pi4gs7hsf41gwf6y02n2ixrqdxnb66ni-emacs-29.3
 --disable-build-details --with-modules --disable-ns-self-contained --with-ns
 --with-native-compilation --with-tree-sitter'

Configured features:
ACL GLIB GMP GNUTLS JPEG JSON LIBXML2 MODULES NATIVE_COMP NOTIFY KQUEUE NS
PDUMPER PNG RSVG SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM
ZLIB

I am using my branch for #57, so there’s a chance it’s related to that, but I don’t think any of the changes there come near this code.

recommendation

Since this seems intermittent and seems to work even when this error occurs, perhaps Auto-Dark should catch Applescript errors and re-report them as warnings with some additional context, like “Received the following error from Applescript when trying to determine whether the system is in dark mode. If Emacs has the appropriate appearance for the current mode, then you may ignore this error, otherwise, please report it at https://github.com/LionyxML/auto-dark-emacs/issues.”

Auto-Dark could also collect some statistics in a few vars about things like

• how often the timer has fired
• how many times the Applescript has been executed
• how many times Applescript has failed
• how many attempts since the last successful Applescript execution

and use these in the warning – either reporting them directly, or determining whether to even show the warning. E.g., if the failure is happening like 1/10 firings or less, maybe don’t even report the warning at all (or write it to *Messages*) – it’s more of an annoyance to the user than helpful, but if it’s failed the last 10 times in a row, we adjust the warning to say “You may need to give Emacs permission to run Applescript in System Settings > Privacy & Security > …” or something².

Footnotes

1. As you can infer from the Backtrace, my standard GNU Emacs 29 has ns-do-applescript, but not ns-system-appearance-change-functions, so it uses the timer, but not osascript (and enabling auto-dark-allow-osascript would have no effect). ↩

2. Is it possible to tell Emacs to request the permissions directly? ↩

[LionyxML]

Hi there @sellout !

I'm trying to catch up with the work/hobby messages mountain, I'm sorry it took so much to answer you :)

These are really nice ideas, thanks for reporting in, I'll keep this issue open for now, to be reminded when doing some improvement on the macOS codebase.

[lukehoersten]

Hi I just wanted to check in two years after reporting #13 - the issue is closed but it has never worked for me. I'm now seeing the following:

I'm using emacs from the default macOS homebrew formula (emacs-plus isn't available in the default homebrew repo).

Using osascript -e 'tell application "System Events" to tell appearance preferences to return dark mode' in combination with(setq auto-dark-allow-osascript t) makes it work but I don't want to have to launch emacs from a terminal. I launch it from the launcher or spotlight, in which case, I'm not running that osascript command first.

(require 'auto-dark) works but then (auto-dark-mode t) fails with this error:

  ns-do-applescript("tell application \"System Events\"\n        tell appe...")
  auto-dark--is-dark-mode-ns()
  auto-dark--is-dark-mode-applescript()
  auto-dark--is-dark-mode()
  auto-dark--check-and-set-dark-mode()
  auto-dark-mode(t)
  eval((auto-dark-mode t) nil)
  elisp--eval-last-sexp(nil)
  eval-last-sexp(nil)
  funcall-interactively(eval-last-sexp nil)
  call-interactively(eval-last-sexp nil nil)
  command-execute(eval-last-sexp)

[sellout]

@lukehoersten First, similar to what @LionyxML said in #13 (comment), but with a newer screenshot, can you check System Settings > Privacy & Security > Automation > Emacs and see if there is a “System Events” entry there and that it is enabled? (This is in the README, but is out-of-date re: where it says the setting is, so needs to be updated.)

If that doesn’t work, could you try

(setq auto-dark-allow-osascript t
      auto-dark-detection-method 'osascript)

As I mention in #61, auto-dark-allow-osascript isn’t helpful on its own. My guess is that when you launch from the terminal, ns-do-applescript isn’t available, and so auto-dark-detection-method is defaulting to osascript in that case, but when launched via Spotlight, ns-do-applescript is found, and so auto-dark-detection-method doesn’t choose osascript.

If that doesn’t work, can you share the result of running

(mapcar (lambda (member) (cons (car member) (symbol-value (car member))))
        (cl-remove-if-not (lambda (member) (eq (cadr member) 'custom-variable))
                          (custom-group-members 'auto-dark nil)))

in each of the terminal- and Spotlight-launched Emacs instances?

That’ll show which settings (if any) differ between the two.

[lukehoersten]

1. System Settings > Privacy & Security > Automation > Emacs and see if there is a “System Events” Emacs.app doesn't request this access. I was not able to add it manually.
2. auto-dark-detection-method 'osascript didn't work
3. Debug output: No diff. Output included for completeness:

Terminal

  (custom-group-members 'auto-dark nil)
  (cl-remove-if-not #'(lambda (member) (eq (car (cdr member)) 'custom-variable)) (custom-group-members 'auto-dark nil))
  (mapcar #'(lambda (member) (cons (car member) (symbol-value (car member)))) (cl-remove-if-not #'(lambda (member) (eq (car (cdr member)) 'custom-variable)) (custom-group-members 'auto-dark nil)))
  eval((mapcar #'(lambda (member) (cons (car member) (symbol-value (car member)))) (cl-remove-if-not #'(lambda (member) (eq (car (cdr member)) 'custom-variable)) (custom-group-members 'auto-dark nil))) nil)
  elisp--eval-last-sexp(nil)
  eval-last-sexp(nil)
  funcall-interactively(eval-last-sexp nil)
  call-interactively(eval-last-sexp nil nil)
  command-execute(eval-last-sexp)

Spotlight

  (custom-group-members 'auto-dark nil)
  (cl-remove-if-not #'(lambda (member) (eq (car (cdr member)) 'custom-variable)) (custom-group-members 'auto-dark nil))
  (mapcar #'(lambda (member) (cons (car member) (symbol-value (car member)))) (cl-remove-if-not #'(lambda (member) (eq (car (cdr member)) 'custom-variable)) (custom-group-members 'auto-dark nil)))
  eval((mapcar #'(lambda (member) (cons (car member) (symbol-value (car member)))) (cl-remove-if-not #'(lambda (member) (eq (car (cdr member)) 'custom-variable)) (custom-group-members 'auto-dark nil))) nil)
  elisp--eval-last-sexp(nil)
  eval-last-sexp(nil)
  funcall-interactively(eval-last-sexp nil)
  call-interactively(eval-last-sexp nil nil)
  command-execute(eval-last-sexp)

[sellout]

1. System Settings > Privacy & Security > Automation > Emacs and see if there is a “System Events” Emacs.app doesn't request this access. I was not able to add it manually.

Damn – this is likely the culprit. It seems there are some possible solutions to this problem, but I have no idea how reliable any of them are. The tl;dr is

1. try tccutil reset Automation org.gnu.Emacs (maybe with sudo?) or
2. install tccplus and follow these steps.

3. Debug output: No diff. Output included for completeness:

I don’t think it’s relevant to this issue any more, as I’m fairly certain your issue is simply the Automation access¹. However, I wanted to mention that both here and in your earlier comment you included the backtrace, but not the error that actually occurred. In the earlier one, I had assumed it was “Applescript error 1”, but with these two commands, I have no idea why custom-group-members would be erroring. (But again, I don’t think it matters for the purposes of this issue.)

Footnotes

1. I think Auto-Dark should probably be catching “Applescript error 1” and producing an error that explains about the necessary System Settings (and hopefully describes the eventual solution to this issue where the permissions aren’t being requested). ↩

[LionyxML]

A quick sidenote on this matter.

Historically, the first version of this package was ONLY osascript, and only MacOS was supported.
With time, many more features were added and the default "fallback to osascript if not Emacs Plus" well, it stopped make sense.

I do think from now on further efforts should be in line with issuing the error to the Messages buffer, while not breaking Emacs startup.

@sellout, am I owing some code review/testing for you? I halted the PR sequence while #64 is being discussed, but if you think some other opened PR can/should be merged first, just ping me! 😄

[sellout]

I do think from now on further efforts should be in line with issuing the error to the Messages buffer, while not breaking Emacs startup.

Yeah, I have to update #62 as described in #66 (comment), and that might be a good place to just make sure Auto-Dark doesn’t use error at all (which still doesn’t fix #64).

@sellout, am I owing some code review/testing for you? I halted the PR sequence while #64 is being discussed, but if you think some other opened PR can/should be merged first, just ping me! 😄

No, sorry, no reviews needed at the moment – I got pulled away with work & family stuff, and haven’t had a chance to tie up things yet. I’ll go over what I have open and see if anything there can be reviewed. My revamped approach to #67 is much improved, but still needs some work.

[LionyxML]

No worries, no rush. I've also been dragged with some personal issues, first things first :)

Nice, I marked #62 as the 'next merge candidate'.

Since we now have tagged commits and semver, I think it would be a good idea to point new merges to the https://github.com/LionyxML/auto-dark-emacs/tree/development branch, what do you think?