[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] battery.el, upower fixes

From: Evgeny Zajcev
Subject: Re: [PATCH] battery.el, upower fixes
Date: Wed, 5 Feb 2020 05:24:25 +0300

ср, 5 февр. 2020 г. в 04:27, Stefan Monnier <address@hidden>:
> 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.


    (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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]