> Hmm, maybe no reason actually. My thought was about providing some way for
> user to autodetect :battery and :line-power device in his init.el and
> explicitly write something like:
>
> (setq battery-upower-device (battery-upower-device-autodetect :battery))
>
> So he states in the config, that he has upower and want error to be rised
> if upower service is not available.
But
(setq battery-status-function #'battery-upower)
already does that in a more direct and reliable way, no?
Yes, reasonable indeed.
> If `battery.el` is loaded unintentionally, then all the custom vars will
> have suitable values to have no warnings. However if user explicitly set
> `battery-upower-device` to invalid value, then warning will arise on
> battery.el load.
Exactly, and even if the user did not intend to use battery in this
session (Elisp files can be loaded "spuriously").
> Otherwise (no warning on invalid `battery-upower-device`), if upower
> service is available - `battery-status-function` will be set to
> upower, and `M-x battery RET` will produce N/A values, and there is no
> clue for the user that he just have invalid value for the
> `battery-upower-device`.
No: `M-x battery` will emit the warning.
So `battery-upower` should check the correctness of the `battery-upower-device` on every call? It would make it heavier, but of course more reliable, because user might change the value of the `batter-upower-device` in runtime
We might have `nil` values for the `battery-upower-device` and `battery-upower-line-power-device` meaning "autodetect". This will require additional call to D-Bus (battery-upower-device-list) on every call to `battery-upower`, probably this is OK. If user want extra speed he just set right values for that vars. Sounds good?
Having `nil` values for those defcustom vars, also won't require putting them after all the functions