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

Philip Kaludercic <[email protected]> writes:

First off thanks for the review.

> I don't get why you need two separate options for this, can you not have
> one major mode with two values (recall that each minor mode is also a
> user option)?  You can use a prefix argument in an interactive setting
> to force the other mode, depending on which of the two you consider to
> be more interesting.

I received similar feedback when I posted the source code to reddit
roughly a month ago, but never reached any conclusion in that
discussion. Here's my thinking on why I built it with two modes:

I reach for display and system sleep prevention for separate use-cases.

System I use the majority of the time, and is about
enabling task completion (e.g. long-running copy, compile, etc.) or
keeping the system responsive to remote requests while I am away (can
reach local dev server on the machine from another location over VPN).

Display sleep would be something I reach for only when I need to watch
some process output scroll by over a long period of time and get tired
of having to tap the keyboard every few minutes to prevent the display
from turning off.

My goal was to keep both use cases readily accessible to users. I'm open
to feedback if there is a more idiomatic way to accomplish this.

For your suggestion to use a single mode with prefix argument:

Isn't there already a convention for minor-mode commands to use a prefix
argument to select between toggle (no argument), unconditionally enable
(positive argument), or unconditionally disable (negative argument)? It
seems like additional prefix argument behavior would clash with that
convention.

> The code looks fine otherwise, and we can add it to ELPA even before
> we release Emacs 31.1.  Just some minor nits:
>
> - For GNU ELPA, you'll have to adjust the copyright line to "Free
>   Software Foundation, Inc.", just like with all the files in emacs.git.
>
> - I would personally set the minimum version to 31.0.90 to avoid
>   confusion with old builds from pre-prerelease that did not have
>   system-sleep failing.  I'd probably bump it to 31.1 when the final
>   release is cut, if for no reason than to help disincentives people
>   from using old development builds.

I'm on board with making both of these edits. Will push these with other
changes (pending the discussion above) or when we get the copyright
assignment paperwork sorted out.

>> My intention is to submit this package to GNU ELPA. I do not currently
>> have an FSF copyright assignment on file but would be happy to complete
>> one.
>
> This is a blocker for progressing anyway right now, but Eli or Sean will
> send you a copy of the form to fill out to get the process started.
> Just ping me when there is news and we can progress.

I assume they will reach out to me, if I need to initiate anything just
let me know.

-- 
Lucas Christian
[email protected]