Add a manual detection mode
#73
Comments
|
Ah, and manual mode should also not run the timer. |
Previously, failing to “determine a viable theme detection mechanism” would error, preventing the rest of `auto-dark-mode` setup from running. This is now a warning, and you are effectively left in “manual” mode. This is technically a fix for LionyxML#66, but doesn’t address all the related changes there. Those will be addressed in LionyxML#62. It also partially addresses LionyxML#73 by adding `auto-dark-toggle-appearance`.
* Set up build & test infrastructure This has a few layers: 1. Eldev, for Emacs package management; 2. Nix, for coördination (e.g., running multiple test configurations, building against multiple Emacs distributions); and 3. garnix, for CI. Each should work without the ones after it, so it is somewhat modular. E.g., garnix could be replaced with GitHub workflows (but at the cost of more configuration). * Appease the linters There are a couple things in here that should be changed: - don’t use `fboundp` on every invocation - don’t set `fill-column` to 167 * Add a test suite There are three pieces to this - “standard” unit tests (currently fairly minimal) - initialization tests that check how various styles of user init behave - a library for simulating the Emacs init process * Pre-load themes & update state when vars set Pre-loading themes helps shift `custom-safe-theme` interactions to when the user sets the variable instead of during initialization or mode change, but this isn’t a full fix for #64, since it doesn’t address the conundrum of `custom-safe-themes` being set after `auto-dark-mode` is enabled. Updating the state when the variables are set fixes the “it seems to only work after one dark mode toggle” issue (which especially crops up when variables are customized after the mode is enabled). Users of the timer likely don’t notice this, as it only takes five seconds for Auto-Dark to fix the state, but the pub/sub detection methods wouldn’t otherwise update until the next mode change. * Set themes even if detection mechanism fails Previously, failing to “determine a viable theme detection mechanism” would error, preventing the rest of `auto-dark-mode` setup from running. This is now a warning, and you are effectively left in “manual” mode. This is technically a fix for #66, but doesn’t address all the related changes there. Those will be addressed in #62. It also partially addresses #73 by adding `auto-dark-toggle-appearance`. * Defer setting old variables Since the old `auto-dark-dark/light-theme` variables have defaults, a traditional configuration (enabling Auto-Dark before customizing vars) can lead to a `default` → `auto-dark-dark/light-theme` → `auto-dark-theme` “flicker” sequence during Emacs initialization. This avoids that by deferring initialization of the old variables until `after-init-mode`, so they only affect the display if both `auto-dark-themes` and `custom-enabled-themes` are `nil`. The consequence is that users of the old variables may have a slightly longer delay until the initial Auto-Dark theme appears. (And also that Auto-Dark has a bit more defensive code to ensure it doesn’t try to set themes before enough is initialized.)
|
Thanks again for all this work @sellout ! Great great stuff here! I think the pipeline passed: https://garnix.io/commit/988121d61e1770cac4105b04218c19fa4c7126b8 Is there a way to make garnix integrated with github? So everybody can see the status? Like a badge or some integration with github actions? |
Yeah, both of those things – you’ll need to authorize the garnix app (https://github.com/apps/garnix-ci), which then gives you GitHub checks for garnix CI and |
|
Noice! Just added them to the development branch. |
I want a way for Auto-Dark to manage the pairs of themes & hooks, but to not do any auto-detection of system mode changes.
This is useful for testing, but also for niche systems that don’t have any of the existing systems. This is already possible, but some changes to make it more ergonomic:
auto-dark-toggle-appearancecommand, so no internal functions need to be called; andauto-dark-modeto not try to re-determine the detection method (either adding amanualdetection method, or moving theauto-dark--determine-detection-methodcall to thedefcustomform and treatingnilas the manual mode)1.Footnotes
I prefer using
nilfor manual mode (read as “there is no detection method”), but perhaps it’s desirable to have a case where re-enabling the theme tries to re-detect the method (as it does now). I think I would prefer having a publicauto-dark-determine-detection-methodcommand that users can explicitly call if they want to re-detect. ↩The text was updated successfully, but these errors were encountered: