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

Philip Kaludercic <[email protected]> writes:

> 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.

As in, you would view the caffeinate-toggle-inhibit-display-sleep
function as essentially another minor mode?

That probably puts us into the pattern of nested minor modes
(i.e. caffeinate-mode, and the "inhibit display sleep" toggle nested
within it), which I don't know of any precedent for (outside of *major*
modes such as the electric-indent function of c-mode).

>>> 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.

Does this make you any more amenable to my current implementation of two
mutually-exclusive minor modes?

Just quickly to summarize the discussion so far on this thread:

We are primarily talking about UX, but reducing code duplication
(context menu entries, documentation strings, etc.) is also desired. The
underlying implementation of using the system-sleep package will not
change much regardless of which UX approach we choose. 

The primary UX concern is how the user selects between system sleep
prevention (allow display sleep) and system + display sleep prevention,
as well as how they switch between the two once one is active. Three
approaches so far:

1. Two mutually-exclusive minor modes (caffeinate-mode and
   display-caffeinate-mode). This is the current implementation.

2. One minor mode caffeinate-mode, with a prefix arg to switch between
   system and display sleep prevention.

   => I believe we agree this approach is not viable due to the prefix arg
   conflicting with the standard prefix arg convention for minor modes.

3. One minor mode caffeinate-mode, with a persistent variable that
   selects between system and display sleep prevention. A second toggle
   command would facilitate flipping the variable on the fly, including
   the necessary releasing and re-creation of the system-sleep
   assertion.

   => This approach is still in discussion.

Do correct me if I twisted anyone's words. Next step: how to reach
consensus? ;)

-- 
Lucas Christian
[email protected]