The API on macOS would expose a pair of C functions to lisp, one would inhibit sleep, perhaps returning an opaque "cookie", the second to revoke the inhibition. The same API can be used to prevent macOS from ever sleeping, if the user wanted that. On Thu, Feb 6, 2025 at 7:21 AM Andrew Cohen wrote: > >>>>> "MA" == Bug reports for GNU Emacs, the Swiss army knife of text > editors writes: > > [...] > > MA> I'm against to touch the D-Bus code because of this. Unneeded > MA> dependency. > > MA> I've assembled a POC patch (appended), which adds the > MA> sleep-event special event to special-event-map, and which adds a > MA> new function insert-special-event, all on C level. With this, > MA> I'm able to eval in the *scratch* buffer > > MA> (defun sleep-handle-event (event) (declare (completion ignore)) > MA> (interactive "e") (message "Event arrived: %S" event)) > > MA> (insert-special-event '(sleep-event t)) > > MA> insert-special-event is not restricted to the sleep-event event, > MA> but shall support all special events, finally. > > MA> Comments? > > > I personally like this approach (but what do I know?) > > I would change the initial special-event-map binding to 'ignore, so that > nothing happens until sleep-wake-mode is activated. My current iteration > installs the handler in the keymap when the mode is activated and > sets it to 'ignore when its disabled. > > I think the remaining big question is how to handle inhibiting sleep > until the sleep-wake code is finished. With dbus.el its straightforward > (although I still don't know how to close the file descriptor returned > from the dbus method in lisp; any help?) but I'm not sure what to do > with other systems. Somehow sleep-wake-mode needs to communicate that > it is OK to release inhibition. I guess one way might be to mimic the > D-Bus method and include a file descriptor in the sleep-event that > blocks sleep until the fd is closed. But this seems kind of contrived. > > Best, > Andy > -- > Andrew Cohen > > > >