Re: [GNU ELPA] New package: caffeinate-mode

Lucas Christian <[email protected]> writes:

> Philip Kaludercic <[email protected]> writes:
>
>> Yes, you are right this wouldn't be a good idea for the minor mode
>> itself.  What might also be worthwhile investigating is if you just want
>> the "display" minor mode to modify if you want to inhibit the display
>> from going to sleep, and nothing else?  So you can both enable or
>> disable it interactively, or set it persistently in your configuration,
>> but you remain to have only a single entry point to the core
>> functionality.  The fact that the two minor modes have almost identical
>> definitions seems to point to this being a viable possibility to me.
>> To preserve the current behavior you'd just have to provide a
>> dynamically computed lighter.
>
> Suppose we have a single minor mode caffeinate-mode, with a sub-mode
> that toggles whether the power assertion also prevents display sleep
> (system sleep is always prevented).
>
> The sub-mode would be driven by a variable,
> caffeinate-inhibit-display-sleep. The user could customize this to set
> their default preference, but if you use both with some regularity, you
> probably don't want to go through the customize interface every time, so
> I assume we would also offer a command, say,
> caffeinate-toggle-inhibit-display-sleep to flip it. I assume the value
> of the variable would persist across caffeinate-mode being enabled and
> disabled.

That would amount to having a minor mode without additional side effects
when enabled or disabled.

> The main challenge here is that I as a user have to remember what
> setting the mode was last in. E.g. if I last used caffeinate with
> display sleep blocking, but now I just want system sleep blocking, I
> would need to run M-x caffeinate-mode followed by M-x
> caffeinate-toggle-inhibit-display-sleep. Whereas with the separate minor
> modes, I just call the one I want. Perhaps that's not that big of a deal
> though--if someone really feels strongly they can add a few trivial
> functions to their init to turn on caffeinate to the preference value
> that they want.

I am not familiar with the system-sleep API, do you think it is feasible
to have the option change the behavior of an existing process?

But otherwise, yes, I think it is better to invite the user to write a
little shim code before you complicate the user interface of the package
with too many options and minor modes.

>> Or do you expect users to use both minor modes equally likely?
>
> I think most would not use the modes equally likely, but I imagine the
> split being closer to 60/40 than 90/10.

In that case I do understand that you think this is something that is
easy to toggle.