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

On Tue, Jul 21, 2026 at 7:46 PM Lucas Christian <[email protected]> wrote:

> 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? ;)
>

Does it even need to be a mode or can it just be a package with a few
commands, e.g., caffeinate, caffeinate-display, decaffeinate, defcustom for
the default display sleep state and interval, and global private variables
for the active sleep token and timer?