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

Lucas Christian <[email protected]> writes:

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

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.

Or do you expect users to use both minor modes equally likely?

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

Yes they will, you shouldn't have to ping, but at least I know I won't
hear about this, so just update us when progress has been made here.