Once an API is agreed in principle, I'd be willing to take a stab at an NS
implementation for sleep/wake events to exercise the API, and so we'd have
both dbus and NS. On macOS, it's basically "will sleep" and "did wake"
events, and I don't think there's a hibernate event.

On Tue, Feb 4, 2025 at 9:56 AM Michael Albinus via Bug reports for GNU
Emacs, the Swiss army knife of text editors <bug-gnu-emacs@gnu.org> wrote:

> Andrew Cohen <acohen@ust.hk> writes:
>
> Hi,
>
> >     >> I have not had much time for Emacs outside of my regular
> >     >> activities, but I made the changes you suggested and have been
> >     >> using the package for the past year. Unless I hear objections,
> >     >> I'll push the package to master sometime soon.
> >
> >     EZ> Thanks, but could we perhaps implement this in a way that is
> >     EZ> less modeled on D-Bus, thus allowing different back-ends on
> >     EZ> other systems?  For example, could we have the D-Bus backend
> >     EZ> inject an input event, which could then be bound to a command,
> >     EZ> instead of directly calling the hooks from a D-Bus event
> >     EZ> handler?  That would allow adding other backend, which will
> >     EZ> generate the same input event "by other means".
> >
> >     EZ> Stefan and Michael, I'd appreciate your comments, both on the
> >     EZ> patch and on my proposal.  Maybe you will have other, better
> >     EZ> design ideas.  (FWIW, I've read Michael's original comments in
> >     EZ> this bug report as saying things similar to what I say above.
> >     EZ> But either I misunderstood or the patch as posted doesn't do
> >     EZ> what Michael suggested back then.)
> >
> >
> > Thanks, I'm happy to make changes. I think I understand what you are
> > suggesting (and what Michael suggested earlier) and it is certainly
> > desirable to make this more independent of D-Bus. My programming skills
> > are extremely rudimentary so it might take some time (or I might fail
> > altogether).
>
> Yes, I still believe my proposal stands. OTOH, nobody else has taken the
> stab over the last months, so I don't know whether such changes will
> happen.
>
> FTR, the majority of my comments on the code are integrated. What's left
> could be done later. What I'm missing is the documentation in the Elisp
> manual, if we integrate it into Emacs core.
>
> > Best,
> > Andy
>
> Best regards Michael.
>
>
>
>