Open sellout opened 1 month ago
Another question I had somewhat related to this …
I had considered unifying the osascript
and powershell
management under a single auto-dark-allow-shell
variable, but one thing that stopped me was noticing that while osascript
is a last resort, powershell
is preferred over reading directly from the registry. Why is that? It seems like powershell
is simply doing the same thing w32-read-registry
is doing, but indirectly, and we don’t have the (fboundp 'w32-read-registry)
check like we do on the Darwin side of things, so why does the powershell
detection method even exist?
This makes a few changes, somewhat independent, but all related:
auto-dark-allow-osascript
to true[^1];osascript
on-demand if neitherns-do-applescript
normac-do-applescript
is available[^2]; andosascript
as a separateauto-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!”). There’s probably something I’m overlooking, but if so, it should be documented.
[^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 ofauto-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 setauto-dark-allow-osascript
”.[^3]: With #59, the two
fboundp
checks added before falling back toosascript
should be more than outweighed by the removal of shell invocation.