Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simplify AppleScript handling #59

Open
wants to merge 8 commits into
base: development
Choose a base branch
from

Conversation

sellout
Copy link
Contributor

@sellout sellout commented Jul 14, 2024

This unifies the three separate copies of the AppleScript used to query the system’s mode.

Each of the three approaches has some changes

  • ns-do-applescript uses AppleScript’s built-in boolean coercion to integer, since it doesn’t support AppleScript booleans;
  • mac-do-applescript seems to return the command output as a string, so this avoids the extra conversion to an AppleScript string and returns the boolean directly; and
  • osascript now uses process-lines instead of shell-command-to-string which avoids shell invocation, the need to handle any shell escaping in the arguments, and the need to trim the result (which is now a list of output lines).

sellout added 2 commits July 14, 2024 10:12
Fix some incorrect indentation and try to keep lines within 80 columns.

This only affects indentation and line breaks in expressions. It doesn’t make
any changes that should affect execution at all (not even introducing escaped
newlines into strings to shorten the line length).

This change is purely cosmetic, but should make some overly-enthusiastic editor
configurations (like mine) happier.
This unifies the three separate copies of the AppleScript used to query the
system’s mode.

Each of the three approaches has some changes
- `ns-do-applescript` uses AppleScript’s built-in boolean coercion to integer,
  since it doesn’t support AppleScript booleans;
- `mac-do-applescript` _seems_ to return the command output as a string, so this
  avoids the extra conversion to an AppleScript string and returns the boolean
  directly; and
- `osascript` now uses `process-lines` instead of `shell-command-to-string`
  which avoids shell invocation, the need to handle any shell escaping in the
  arguments, and the need to trim the result (which is now a list of output
  lines).
@sellout
Copy link
Contributor Author

sellout commented Jul 14, 2024

I tested both the ns-do-applescript and osascript approaches, but I’m not sure where mac-do-applescript comes from. If you let me know, I will mention it in the doc/comments and test that approach as well.

sellout added a commit to sellout/auto-dark-emacs that referenced this pull request Jul 14, 2024
This makes a few changes, somewhat independent, but all related:
* defaults `auto-dark-allow-osascript` to true[^1];
* falls back to `osascript` on-demand if neither `ns-do-applescript` nor
  `mac-do-applescript` is available[^2]; and
* removes `osascript` as a separate `auto-dark-detection-method`[^3].

These can be easily separated depending on which, if any, you think are
improvements.

[^1]: I don’t know why this is even a variable. If it’s not allowed, then there
is no way to use Auto-Dark on systems that require it, and the failure mode is
opaque (“Could not determine a viable theme detection mechanism!”).

[^2]: If this change isn’t made, then the error message “Try setting
`auto-dark-allow-osascript` to t” doesn’t make sense, as it’s only reported in a
location where the value of `auto-dark-allow-osascript` has no effect. The
alternative is to change the error message to something like
“`auto-dark-detection-method` indicates that this Emacs build has AppleScript
support, but none could be found. Either rebuild Emacs with AppleScript support
or change the detection method and set `auto-dark-allow-osascript`”.

[^3]: With LionyxML#59, the two `fboundp` checks added before falling back to
`osascript` should be more than outweighed by the removal of shell invocation.
sellout added a commit to sellout/auto-dark-emacs that referenced this pull request Jul 14, 2024
This makes a few changes, somewhat independent, but all related:
* defaults `auto-dark-allow-osascript` to true[^1];
* falls back to `osascript` on-demand if neither `ns-do-applescript` nor
  `mac-do-applescript` is available[^2]; and
* removes `osascript` as a separate `auto-dark-detection-method`[^3].

These can be easily separated depending on which, if any, you think are
improvements.

[^1]: I don’t know why this is even a variable. If it’s not allowed, then there
is no way to use Auto-Dark on systems that require it, and the failure mode is
opaque (“Could not determine a viable theme detection mechanism!”).

[^2]: If this change isn’t made, then the error message “Try setting
`auto-dark-allow-osascript` to t” doesn’t make sense, as it’s only reported in a
location where the value of `auto-dark-allow-osascript` has no effect. The
alternative is to change the error message to something like
“`auto-dark-detection-method` indicates that this Emacs build has AppleScript
support, but none could be found. Either rebuild Emacs with AppleScript support
or change the detection method and set `auto-dark-allow-osascript`”.

[^3]: With LionyxML#59, the two `fboundp` checks added before falling back to
`osascript` should be more than outweighed by the removal of shell invocation.
@LionyxML
Copy link
Owner

mac-do-applescript

It comes from https://github.com/railwaycat/homebrew-emacsmacport this brew formulae does things a bit differently.

@sellout
Copy link
Contributor Author

sellout commented Oct 17, 2024

If something like #74 gets in, I’d update this to include system & emacs-dist specific tests. E.g., testing mac-do-applescript detection and operation for emacs-macport, and ns-do-applescript testing on other Emacses on macOS.

@sellout
Copy link
Contributor Author

sellout commented Oct 18, 2024

I just discovered there’s an additional way to check the appearance on Emacs-macport:

(pcase (plist-get :appearance (mac-application-state))
  ("NSAppearanceAqua" 'light)
  ("NSAppearanceDarkAqua" 'dark)
  (appearance
   (lwarn 'auto-dark :warning "Unknown system appearance “%s”" appearance)
   nil))

This avoids AppleScript, so I think it’s both faster than mac-do-applescript and doesn’t require “System Events” access. I wish it could help with #58, but that seems restricted to non-macport users. (mac-application-state is recommended in the documentation for mac-effective-appearance-change-hook.)

Wondering if you had already seen this and ruled it out for some reason.

@StefPac
Copy link

StefPac commented Oct 27, 2024

this PR would solve another problem: by using the shell for osascript, when a tramp buffer is active, the shell used will be the remote one, which may not be on a Darwin system and fail to run the dark mode check. @LionyxML are you planning to merge this when ready? if not I'll submit a different issue/PR to solve the problem

@sellout
Copy link
Contributor Author

sellout commented Oct 27, 2024

this PR would solve another problem: by using the shell for osascript, when a tramp buffer is active, the shell used will be the remote one, which may not be on a Darwin system and fail to run the dark mode check. @LionyxML are you planning to merge this when ready? if not I'll submit a different issue/PR to solve the problem

Now that #74 has been merged into the development branch, I’ll update this with tests and I can also test the macport version, so this can probably get in shortly.

@sellout sellout changed the base branch from master to development December 15, 2024 21:13
@sellout
Copy link
Contributor Author

sellout commented Dec 15, 2024

I updated this branch, re-targeted against the development branch, and added a bit of improvement around #58.

I think this should go in after #60.

This error occurs mostly when Emacs doesn’t have System Event permissions, but
it also pops up in other cases sometimes (LionyxML#58). This doesn’t fix the issue, but
downgrades it from an error to a warning, and tries to improve the messaging.
@sellout sellout marked this pull request as ready for review December 20, 2024 07:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants