Re: master 6b11687555c: New user option native-comp-async-on-battery-power

[Sean Whitton]

Hello,

On Fri 02 May 2025 at 04:53pm +03, Eli Zaretskii wrote:

> That'd need every back-end to be extended, no?  That's a disadvantage.
>
> Could we instead base this on information already available that has a
> fixed form known in advance?  For example, if %b produces either an
> empty string "" or "+", we are either at full battery capacity or
> charging.  If "" is not definitive enough, we could look at %p and
> compare with "100%" instead.  Would that be good enough?

I think that would be at least as good as what I implemented.  I could
combine it with Stefan's suggestion to make a pretty decent heuristic.
I'll see what I can do.

> If it's good enough. the advantage is that this doesn't require any
> changes in the back-ends.

Right.  I was thinking I'd just go through and extend them all.

We've had battery.el for many years and this is the first time we want
to use this information machine-readably, so perhaps it is indeed
overkill to be extending the API.  And it's not exactly a pleasant
extension.

> Btw, I would suggest to consider an extension of the feature: if
> native-comp-async-on-battery-power is a number, it is interpreted as
> the threshold for battery capacity percentage below which async
> compilations should not be started.
>
> WDYT?

I'd be happy to implement this if someone comes along asking for it, but
I don't think it makes sense to implement in advance.

Based on talking to developers who use laptops (and my own experience),
they plug in their laptops to run compilations mostly to try to stop
their battery getting hot, not so much for the sake of avoiding running
down its current charge.  That's because letting your battery get hot
reduces its overall lifespan.  Also, many platforms turn down CPU speed
while on battery power, and CPU matters a lot for compilation.

-- 
Sean Whitton