GNU bug report logs -
#63620
30.0.50; [Feature Request] run hooks on sleep/wake
Previous Next
To reply to this bug, email your comments to 63620 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Sat, 20 May 2023 23:25:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Andrew Cohen <acohen <at> ust.hk>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sat, 20 May 2023 23:25:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
I am playing around with various network things (mostly vpn related) and
need Emacs to take certain actions when my laptop sleeps and wakes. This
is easy to do using the existing dbus support (the relevant code is
below, which runs hooks on sleeping and waking) The question is whether
this is useful enough to add to Emacs, and if so the best place to put
it.
Not too long ago, Eric Abrahamsen added gnus-dbus.el which is similar,
although for a single purpose: to close gnus server network connections
on sleep. This has a single entry point for the user: set
'gnus-dbus-close-on-sleep to t to enable the feature.
Options:
1. Do nothing (this isn't useful enough to change anything, and I can just
keep using my own code).
2. Add a small package dbus-sleep.el. I would also remove gnus-dbus.el
but leave the variable 'gnus-dbus-close-on-sleep and use it to control
the installation of appropriate gnus functions to the new hooks.
3. 2. Add the new code to the existing dbus.el. I would also remove
gnus-dbus.el but leave the variable 'gnus-dbus-close-on-sleep and use it
to control the installation of appropriate functions to the new hooks.
I mostly favor adding it to dbus.el. The argument against: dbus.el is
focused on providing language bindings for the D-Bus API rather than a
user-feature. The removal of gnus-dbus.el shouldn't cause any problem
since I would maintain the same functionality enabled by the same
variable, so no user-visible change.
Advice?
;;; Code:
(require 'dbus)
(defcustom dbus-sleep-sleep-hook nil
"Hook to run on sleep."
:group 'dbus-sleep
:type 'hook)
(defcustom dbus-sleep-wake-hook nil
"Hook to run on wake."
:group 'dbus-sleep
:type 'hook)
(defvar dbus-sleep-registration-object nil
"Object returned from `dbus-register-signal'.
This is used to unregister the signal.")
;;;###autoload
(defun dbus-sleep-enable ()
"Use `dbus-register-signal' to close servers on sleep."
(interactive)
;; Don't enable if it's already enabled.
(when (and (featurep 'dbusbind) (not dbus-sleep-registration-object))
(setq dbus-sleep-registration-object
(dbus-register-signal :system
"org.freedesktop.login1"
"/org/freedesktop/login1"
"org.freedesktop.login1.Manager"
"PrepareForSleep"
#'dbus-sleep-handler))))
(defun dbus-sleep-disable ()
"Unregister sleep signal."
(interactive)
(condition-case nil
(dbus-unregister-object
dbus-sleep-registration-object)
(setq dbus-sleep-registration-object nil)
(wrong-type-argument nil)))
(defun dbus-sleep-handler (sleep-wake)
"Handler to execute sleep and wake functions.
SLEEP-WAKE is t on sleeping and nil on waking."
(ignore-errors
(if sleep-wake
(run-hooks 'dbus-sleep-sleep-hook)
(run-hooks 'dbus-sleep-wake-hook))))
--
Andrew Cohen
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Sun, 21 May 2023 08:14:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 63620 <at> debbugs.gnu.org (full text, mbox):
Andrew Cohen <acohen <at> ust.hk> writes:
Hi Andrew,
> 2. Add a small package dbus-sleep.el. I would also remove gnus-dbus.el
> but leave the variable 'gnus-dbus-close-on-sleep and use it to control
> the installation of appropriate gnus functions to the new hooks.
>
> 3. Add the new code to the existing dbus.el. I would also remove
> gnus-dbus.el but leave the variable 'gnus-dbus-close-on-sleep and use it
> to control the installation of appropriate functions to the new hooks.
>
> I mostly favor adding it to dbus.el. The argument against: dbus.el is
> focused on providing language bindings for the D-Bus API rather than a
> user-feature. The removal of gnus-dbus.el shouldn't cause any problem
> since I would maintain the same functionality enabled by the same
> variable, so no user-visible change.
Using D-Bus is just an implementation detail. What you want are
handlers, which are invoked when your laptop falls asleep or awakes.
A general package could implement it using D-Bus if available, or using
something else if there's no D-Bus. See battery.el, which uses the D-Bus
service "org.freedesktop.UPower" only if possible. Your package might be
called sleep.el or alike.
Your code uses the D-Bus service "org.freedesktop.login1", which isn't
part of the basic D-Bus spec. So it isn't suited for dbus.el anyway.
> ;;;###autoload
> (defun dbus-sleep-enable ()
> "Use `dbus-register-signal' to close servers on sleep."
> (interactive)
I would make it rather a global minor mode, that you can enable/disable
it easily.
> ;; Don't enable if it's already enabled.
> (when (and (featurep 'dbusbind) (not dbus-sleep-registration-object))
Perhaps, you check also for the service "org.freedesktop.login1", like
--8<---------------cut here---------------start------------->8---
(member "org.freedesktop.login1" (dbus-list-activatable-names :system))
--8<---------------cut here---------------end--------------->8---
This check might return nil for several reasons, like the system bus is
not running, or you don't have permissions to speak to the system bus,
or the service simply doesn't exist.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Mon, 05 Jun 2023 13:07:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 63620 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Dear Michael
>>>>> "MA" == Michael Albinus <michael.albinus <at> gmx.de> writes:
[...]
MA> Using D-Bus is just an implementation detail. What you want are
MA> handlers, which are invoked when your laptop falls asleep or
MA> awakes.
Yes, of course you are right!
MA> A general package could implement it using D-Bus if available,
MA> or using something else if there's no D-Bus. See battery.el,
MA> which uses the D-Bus service "org.freedesktop.UPower" only if
MA> possible. Your package might be called sleep.el or alike.
I am not familiar with other methods for detecting sleep/wake, so I just
have dbus at the moment. But if anyone knows of something else
(especially on windows) it can then be added.
[...]
MA> I would make it rather a global minor mode, that you can
MA> enable/disable it easily.
Yes, that is a better idea.
[...]
MA> Perhaps, you check also for the service
MA> "org.freedesktop.login1", like
MA> (member "org.freedesktop.login1" (dbus-list-activatable-names
MA> :system))
OK, added.
I've now put everything together and modified the gnus code to use the
new sleep.el. But I remain unsure if I should remove gnus-dbus.el
entirely (everything remains the same for the user: setting
gnus-dbus-close-on-sleep to a non-nil value will enable the feature
using the global minor mode rather than gnus-dbus). And is sleep.el
something worth adding?
[sleep.el (application/emacs-lisp, inline)]
[Message part 3 (text/plain, inline)]
--
Andrew Cohen
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Sat, 10 Jun 2023 10:48:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 63620 <at> debbugs.gnu.org (full text, mbox):
Andrew Cohen <acohen <at> ust.hk> writes:
> Dear Michael
Hi Andrew,
sorry for the delayed answer, I've been busy ...
> I've now put everything together and modified the gnus code to use the
> new sleep.el. But I remain unsure if I should remove gnus-dbus.el
> entirely (everything remains the same for the user: setting
> gnus-dbus-close-on-sleep to a non-nil value will enable the feature
> using the global minor mode rather than gnus-dbus). And is sleep.el
> something worth adding?
It depends whether sleep.el will be added to vanilla Emacs, or as GNU
ELPA package. It's not my decision, but I lobby for the former.
In this case, it could be used in gnus-dbus.el.
Just some few comments on the code
> ;;; sleep.el --- run hooks on sleep and wake -*- lexical-binding:t -*-
I would be more precise. You don't mean sleeping Emacs or another
application, but you mean sleeping the machine on OS level. Say it so.
> ;;; This global minor mode enables evaluating code when the device
> ;;; running Emacs enters or leaves the sleep state. Two hooks are
> ;;; used, sleep-sleep-hook and sleep-wake-hook, run when the system
> ;;; detects that it is going to sleep or waking up. Currently only a
> ;;; dbus interface to detect sleep state change is implemented.
Please quote Lisp objects like `sleep-sleep-hook'. D-Bus is spelled out
in commentaries as D-Bus.
> (defgroup sleep nil
> "Run hooks on entering/leaving the sleep state."
> :group 'hardware)
>
> (defcustom sleep-sleep-hook nil
> "Hook to run on entering sleep."
> :group 'sleep
> :type 'hook)
>
> (defcustom sleep-wake-hook nil
> "Hook to run on leaving sleep."
> :group 'sleep
> :type 'hook)
These are the user visible objects. Please be precise what is going to
sleep. The machine or device.
> Run sleep-sleep-hook and sleep-wake-hook as appropriate."
Please quote sleep-sleep-hook.
> (unless sleep-registration-object
> (setq sleep-registration-object
> (dbus-register-signal :system
> "org.freedesktop.login1"
> "/org/freedesktop/login1"
> "org.freedesktop.login1.Manager"
> "PrepareForSleep"
> #'sleep-handler))))
I would also protect against D-Bus errors. Like
(ignore-error dbus-error
(unless sleep-registration-object
(setq sleep-registration-object
(dbus-register-signal
:system "org.freedesktop.login1"
"/org/freedesktop/login1" "org.freedesktop.login1.Manager"
"PrepareForSleep" #'sleep-handler))))
> (condition-case nil
> (progn
> (dbus-unregister-object
> sleep-registration-object)
> (setq sleep-registration-object nil))
> (wrong-type-argument nil)))
Aka
(ignore-error (dbus-error wrong-type-argument)
(dbus-unregister-object
sleep-registration-object)
(setq sleep-registration-object nil))
> When sleep-wake-mode is enabled, Emacs will execute the hooks
Please quote sleep-wake-mode.
> support dbus detection of sleep state change."
D-Bus is spelled out ...
Furthermore, it would be nice if you add
- documentation in lispref node "(elisp) System Interface". I'm not sure
whether it is good for a new subnode, or whether it shall be
documented in "(elisp) System Environment". This documentation should
also give a practical example for functions in sleep-sleep-hook and
sleep-wake-hook.
- adding the functionality to etc/NEWS
- if possible, adding tests in test/lisp/sleep-tests.el
Best regards, Michael.
Added tag(s) patch.
Request was from
Stefan Kangas <stefankangas <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Mon, 11 Sep 2023 23:14:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Tue, 04 Feb 2025 03:21:02 GMT)
Full text and
rfc822 format available.
Message #19 received at 63620 <at> debbugs.gnu.org (full text, mbox):
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.
Best,
Andy
ea288bd05e7d11740f5d580771ed7ca5ad496b15
Author: Andrew G Cohen <cohen <at> andy.bu.edu>
AuthorDate: Thu Mar 21 11:06:36 2024 +0800
Commit: Andrew G Cohen <cohen <at> andy.bu.edu>
CommitDate: Tue Feb 4 11:14:26 2025 +0800
Parent: c54d8d4cbe0 New functions to suspend and resume gnus demon
Merged: master
Contained: feature/igc
Follows: emacs-29.1.90 (176369)
New sleep-wake-mode to run hooks on sleep state change
* lisp/sleep.el: New global minor mode. When enabled, the hooks
sleep-wake-hook and sleep-sleep-hook are run on the corresponding sleep
state change.
2 files changed, 112 insertions(+)
etc/NEWS | 6 ++++
lisp/sleep.el | 106 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
modified etc/NEWS
@@ -1015,6 +1015,12 @@ destination window is chosen using 'display-buffer-alist'. Example:
* New Modes and Packages in Emacs 31.1
+** New global minor mode 'sleep-wake'.
+With this minor mode enabled, the hooks 'sleep-sleep-hook' and
+'sleep-wake-hook' are run when the device running Emacs enters or leaves
+the sleep state. Currently only D-Bus detection of device sleep state
+changes is available.
+
* Incompatible Lisp Changes in Emacs 31.1
new file lisp/sleep.el
@@ -0,0 +1,106 @@
+;;; sleep.el --- run hooks on device sleep and wake -*- lexical-binding:t -*-
+
+;; Copyright (C) 2025 Free Software Foundation, Inc.
+
+;; Author: Andrew Cohen <>
+;; Maintainer: emacs-devel <at> gnu.org
+;; Keywords:
+
+;; This file is part of GNU Emacs.
+
+;; GNU Emacs is free software: you can redistribute it and/or modify
+;; it under the terms of the GNU General Public License as published by
+;; the Free Software Foundation, either version 3 of the License, or
+;; (at your option) any later version.
+
+;; GNU Emacs is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+;; GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public License
+;; along with GNU Emacs. If not, see <https://www.gnu.org/licenses/>.
+
+;;; Commentary:
+
+;;; This global minor mode enables evaluating code when the device
+;;; running Emacs enters or leaves the sleep state. The hooks
+;;; `sleep-sleep-hook' and `sleep-wake-hook' are run when the system
+;;; detects that it is going to sleep or waking up. Currently only a
+;;; D-Bus interface to detect sleep state change is implemented.
+
+;;; Code:
+
+(require 'dbus)
+
+(defgroup sleep nil
+ "Run hooks on device entering/leaving the sleep state."
+ :group 'hardware)
+
+(defcustom sleep-sleep-hook nil
+ "Hook to run on device entering sleep."
+ :group 'sleep
+ :type 'hook)
+
+(defcustom sleep-wake-hook nil
+ "Hook to run on device leaving sleep."
+ :group 'sleep
+ :type 'hook)
+
+(defvar sleep-registration-object nil
+ "Object returned from `dbus-register-signal'.
+This is recorded so that the signal may be unregistered.")
+
+
+(defun sleep-dbus-enable ()
+ "Enable D-Bus detection of device sleep/wake state change.
+Run `sleep-sleep-hook' and `sleep-wake-hook' as appropriate."
+ (unless sleep-registration-object
+ (setq sleep-registration-object
+ (dbus-register-signal :system
+ "org.freedesktop.login1"
+ "/org/freedesktop/login1"
+ "org.freedesktop.login1.Manager"
+ "PrepareForSleep"
+ #'sleep-handler))))
+
+(defun sleep-dbus-disable ()
+ "Disable D-Bus detection of device sleep/wake state change."
+ (condition-case nil
+ (progn
+ (ignore-error (dbus-error wrong-type-argument)
+ (dbus-unregister-object
+ sleep-registration-object))
+ (setq sleep-registration-object nil))
+ (wrong-type-argument nil)))
+
+(defun sleep-handler (sleep-wake)
+ "Handler to execute sleep and wake functions.
+SLEEP-WAKE is t on sleeping and nil on waking."
+ (ignore-errors
+ (if sleep-wake
+ (run-hooks 'sleep-sleep-hook)
+ (run-hooks 'sleep-wake-hook))))
+
+;;;###autoload
+(define-minor-mode sleep-wake-mode
+ "Toggle sleep/wake detection.
+
+With `sleep-wake-mode' enabled, the hooks `sleep-sleep-hook' and
+`sleep-wake-hook' will be executed when the device enters or leaves the
+sleep state. This is currently only available on systems that support
+D-Bus detection of sleep state changes."
+ :global t
+ :group 'sleep
+ (cond
+ ((and (featurep 'dbusbind)
+ (member "org.freedesktop.login1"
+ (dbus-list-activatable-names :system)))
+ (if sleep-wake-mode
+ (sleep-dbus-enable)
+ (sleep-dbus-disable)))
+ (t
+ (message "No sleep/wake detection method found."))))
+
+(provide 'sleep)
+;;; sleep.el ends here
--
Andrew Cohen
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Tue, 04 Feb 2025 13:17:01 GMT)
Full text and
rfc822 format available.
Message #22 received at 63620 <at> debbugs.gnu.org (full text, mbox):
> Cc: 63620 <at> debbugs.gnu.org
> From: Andrew Cohen <acohen <at> ust.hk>
> Date: Tue, 04 Feb 2025 11:19:55 +0800
>
> 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.
Thanks, but could we perhaps implement this in a way that is less
modeled on D-Bus, thus allowing different back-ends on other systems?
For example, could we have the D-Bus backend inject an input event,
which could then be bound to a command, instead of directly calling
the hooks from a D-Bus event handler? That would allow adding other
backend, which will generate the same input event "by other means".
Stefan and Michael, I'd appreciate your comments, both on the patch
and on my proposal. Maybe you will have other, better design ideas.
(FWIW, I've read Michael's original comments in this bug report as
saying things similar to what I say above. But either I misunderstood
or the patch as posted doesn't do what Michael suggested back then.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Tue, 04 Feb 2025 13:40:01 GMT)
Full text and
rfc822 format available.
Message #25 received at 63620 <at> debbugs.gnu.org (full text, mbox):
>>>>> "EZ" == Eli Zaretskii <eliz <at> gnu.org> writes:
>> Cc: 63620 <at> debbugs.gnu.org From: Andrew Cohen <acohen <at> ust.hk>
>> Date: Tue, 04 Feb 2025 11:19:55 +0800
>>
>> 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).
Best,
Andy
--
Andrew Cohen
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Tue, 04 Feb 2025 14:50:02 GMT)
Full text and
rfc822 format available.
Message #28 received at 63620 <at> debbugs.gnu.org (full text, mbox):
> From: Andrew Cohen <acohen <at> ust.hk>
> Cc: <michael.albinus <at> gmx.de>, Stefan Monnier <monnier <at> iro.umontreal.ca>,
> <63620 <at> debbugs.gnu.org>
> Date: Tue, 04 Feb 2025 21:38:53 +0800
>
> 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).
Thanks, and don't hesitate to ask questions where you have
difficulties. I'm sure you will find here quite a few people willing
to help.
To make it clear: I think this is a very useful feature to have in
Emacs, given today's proliferation of laptops and devices that like to
go to sleep, so I hope we will be able to make it work on as many
platforms as possible. Which is why I think we should try
implementing it using the most portable and flexible mechanisms we
have of triggering stuff in Emacs.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Tue, 04 Feb 2025 14:56:01 GMT)
Full text and
rfc822 format available.
Message #31 received at 63620 <at> debbugs.gnu.org (full text, mbox):
Andrew Cohen <acohen <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Tue, 04 Feb 2025 15:24:02 GMT)
Full text and
rfc822 format available.
Message #34 received at 63620 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> gnu.org> wrote:
> Andrew Cohen <acohen <at> 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.
>
>
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Tue, 04 Feb 2025 15:32:02 GMT)
Full text and
rfc822 format available.
Message #37 received at 63620 <at> debbugs.gnu.org (full text, mbox):
> From: Ship Mints <shipmints <at> gmail.com>
> Date: Tue, 4 Feb 2025 10:21:05 -0500
> Cc: Andrew Cohen <acohen <at> ust.hk>, 63620 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
> Stefan Monnier <monnier <at> iro.umontreal.ca>
>
> 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.
What I had in mind is basically to have the D-Bus handler push a
special event onto unread-command-events, and then that event could be
bound to a command.
Michael and Stefan, does it make sense to work like that with D-Bus?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Tue, 04 Feb 2025 15:38:01 GMT)
Full text and
rfc822 format available.
Message #40 received at 63620 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
This would be kbd_buffer_store_event?
On Tue, Feb 4, 2025 at 10:31 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Ship Mints <shipmints <at> gmail.com>
> > Date: Tue, 4 Feb 2025 10:21:05 -0500
> > Cc: Andrew Cohen <acohen <at> ust.hk>, 63620 <at> debbugs.gnu.org, Eli Zaretskii <
> eliz <at> gnu.org>,
> > Stefan Monnier <monnier <at> iro.umontreal.ca>
> >
> > 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.
>
> What I had in mind is basically to have the D-Bus handler push a
> special event onto unread-command-events, and then that event could be
> bound to a command.
>
> Michael and Stefan, does it make sense to work like that with D-Bus?
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Tue, 04 Feb 2025 15:39:02 GMT)
Full text and
rfc822 format available.
Message #43 received at 63620 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> 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.
>
> What I had in mind is basically to have the D-Bus handler push a
> special event onto unread-command-events, and then that event could be
> bound to a command.
>
> Michael and Stefan, does it make sense to work like that with D-Bus?
Sure, no problem for D-Bus. This could be done in sleep-handler, instead
of running sleep-sleep-hook and sleep-wake-hook.
The event should have a boolean argument, for on/off (or sleep/wake,
however we name it).
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Tue, 04 Feb 2025 15:43:02 GMT)
Full text and
rfc822 format available.
Message #46 received at 63620 <at> debbugs.gnu.org (full text, mbox):
Ship Mints <shipmints <at> gmail.com> writes:
> This would be kbd_buffer_store_event?
On Lisp level, adding the event to unread-command-events, as Eli
said. See a similar handling in dbus-call-method.
> What I had in mind is basically to have the D-Bus handler push a
> special event onto unread-command-events, and then that event
> could be
> bound to a command.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Tue, 04 Feb 2025 15:54:02 GMT)
Full text and
rfc822 format available.
Message #49 received at 63620 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
For macOS, we'll have to do this via objective-c so would be the
lower-level function that would post the event.
On Tue, Feb 4, 2025 at 10:42 AM Michael Albinus <michael.albinus <at> gmx.de>
wrote:
> Ship Mints <shipmints <at> gmail.com> writes:
>
> > This would be kbd_buffer_store_event?
>
> On Lisp level, adding the event to unread-command-events, as Eli
> said. See a similar handling in dbus-call-method.
>
> > What I had in mind is basically to have the D-Bus handler push a
> > special event onto unread-command-events, and then that event
> > could be
> > bound to a command.
>
> Best regards, Michael.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Tue, 04 Feb 2025 16:13:02 GMT)
Full text and
rfc822 format available.
Message #52 received at 63620 <at> debbugs.gnu.org (full text, mbox):
> From: Ship Mints <shipmints <at> gmail.com>
> Date: Tue, 4 Feb 2025 10:35:03 -0500
> Cc: michael.albinus <at> gmx.de, acohen <at> ust.hk, 63620 <at> debbugs.gnu.org,
> monnier <at> iro.umontreal.ca
>
> This would be kbd_buffer_store_event?
Basically, yes. But I meant to do it in Lisp, not in C.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Tue, 04 Feb 2025 16:16:02 GMT)
Full text and
rfc822 format available.
Message #55 received at 63620 <at> debbugs.gnu.org (full text, mbox):
> From: Ship Mints <shipmints <at> gmail.com>
> Date: Tue, 4 Feb 2025 10:51:11 -0500
> Cc: Eli Zaretskii <eliz <at> gnu.org>, acohen <at> ust.hk, 63620 <at> debbugs.gnu.org,
> monnier <at> iro.umontreal.ca
>
> For macOS, we'll have to do this via objective-c so would be the lower-level function that would post the
> event.
Yes, platforms that get the event from their window-systems should do
it in C. Then we'd need to define a new event kind and inject it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Tue, 04 Feb 2025 18:15:01 GMT)
Full text and
rfc822 format available.
Message #58 received at 63620 <at> debbugs.gnu.org (full text, mbox):
> What I had in mind is basically to have the D-Bus handler push a
> special event onto unread-command-events, and then that event could be
> bound to a command.
> Michael and Stefan, does it make sense to work like that with D-Bus?
It would likely be bound in `special-event-map`, yes, that makes sense.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Wed, 05 Feb 2025 12:52:01 GMT)
Full text and
rfc822 format available.
Message #61 received at 63620 <at> debbugs.gnu.org (full text, mbox):
>>>>> "EZ" == Eli Zaretskii <eliz <at> gnu.org> writes:
EZ> Thanks, and don't hesitate to ask questions where you have
EZ> difficulties. I'm sure you will find here quite a few people
EZ> willing to help.
OK, I have almost no idea what I am doing. I am trying to understand how
to use unread-command-events to make this work. I guess a new event
(sleep-event) will get added in the C code? Then backends other than
dbus will generate this event when a system sleeps or wakes, and we have
a handler installed like
(define-key special-event-map [sleep-event] 'handle-sleep-event)
with the function 'handle-sleep-event that runs the appropriate hooks.
For the dbus backend we install a dbus callback that injects the
sleep-event onto unread-command-events, which would then trigger the
'handle-sleep-event function.
So I thought I would play around a bit. I tried installing [sleep-event]
in the special-event map, but when I push the sleep-event onto
unread-command-events I get an error: "<sleep-event> is undefined".
After playing around I found that if I also install it in the global
keymap, it works (that is, pushing a sleep-event onto
unread-command-events then triggers the handler).
So how exactly do I add a new sleep-event to the C source? I tried
copying how its done for dbus-event in keyboard.c and termhooks.h (I'm
only trying to create such an event in lisp so I didn't worry about
generating such an event in C). Is this right? And do I always have to
install the handler in the global keymap (just to test this I tried
pushing an existing dbus-event onto unread-command-events, and also get
"dbus-event is undefined" unless I install a handler on the global
keymap. So it seems that I do. I also notice that other special events,
like delete-frame, have handlers installed in both the global keymap and
the special-event-map).
Sorry for the very naive questions. Assuming that my understanding is
correct I think I can make the necessary modifications to the lisp
package. Then the C code to generate the sleep-event on other systems
can be added.
Best,
Andy
--
Andrew Cohen
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Wed, 05 Feb 2025 13:28:02 GMT)
Full text and
rfc822 format available.
Message #64 received at 63620 <at> debbugs.gnu.org (full text, mbox):
>>>>> "AC" == Andrew Cohen <acohen <at> ust.hk> writes:
[...]
AC> So how exactly do I add a new sleep-event to the C source? I
AC> tried copying how its done for dbus-event in keyboard.c and
AC> termhooks.h (I'm only trying to create such an event in lisp so
AC> I didn't worry about generating such an event in C). Is this
AC> right? And do I always have to install the handler in the global
AC> keymap (just to test this I tried pushing an existing dbus-event
AC> onto unread-command-events, and also get "dbus-event is
AC> undefined" unless I install a handler on the global keymap. So
AC> it seems that I do. I also notice that other special events,
AC> like delete-frame, have handlers installed in both the global
AC> keymap and the special-event-map).
And maybe answering my own questions:
According the the elisp manual special events "cannot be unread with
‘unread-command-events’". Not sure exactly what this means (and I
haven't yet read the code to figure it out) but it certainly appears
that special events can't trigger a function bound in special-event-map
by pushing an event onto unread-command-events. But that's probably OK,
since we can /also/ bind the handler to the special event in the global
keymap, as is done for several of the existing special events
(delete-frame, make-frame-visible, iconify-frame). Then we can trigger
the event directly in C by generating the special event, or
synthetically in Lisp by pushing onto unread-command-events.
I'll assume that this is OK unless I hear otherwise and make changes to
the package accordingly.
Best,
Andy
--
Andrew Cohen
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Wed, 05 Feb 2025 15:30:02 GMT)
Full text and
rfc822 format available.
Message #67 received at 63620 <at> debbugs.gnu.org (full text, mbox):
> According the the elisp manual special events "cannot be unread with
> ‘unread-command-events’".
Oh, right! So pushing to `unread-command-events` will only work if the
binding is made in a normal map. That's not the end of the world, but
it's not ideal. E.g. it doesn't really make sense to have the behavior
depend on the mode of the current buffer, and it seems undesirable to
fail to run the binding if you happened to type `C-x` just
before sleeping.
Hmm...
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Wed, 05 Feb 2025 18:22:01 GMT)
Full text and
rfc822 format available.
Message #70 received at 63620 <at> debbugs.gnu.org (full text, mbox):
>> According the the elisp manual special events "cannot be unread with
>> ‘unread-command-events’".
> Oh, right! So pushing to `unread-command-events` will only work if the
> binding is made in a normal map. That's not the end of the world, but
> it's not ideal. E.g. it doesn't really make sense to have the behavior
> depend on the mode of the current buffer, and it seems undesirable to
> fail to run the binding if you happened to type `C-x` just
> before sleeping.
Maybe a hook is not such a bad idea after all.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Wed, 05 Feb 2025 20:23:02 GMT)
Full text and
rfc822 format available.
Message #73 received at 63620 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 63620 <at> debbugs.gnu.org,
> michael.albinus <at> gmx.de
> Date: Wed, 05 Feb 2025 13:21:41 -0500
>
> >> According the the elisp manual special events "cannot be unread with
> >> ‘unread-command-events’".
> > Oh, right! So pushing to `unread-command-events` will only work if the
> > binding is made in a normal map. That's not the end of the world, but
> > it's not ideal. E.g. it doesn't really make sense to have the behavior
> > depend on the mode of the current buffer, and it seems undesirable to
> > fail to run the binding if you happened to type `C-x` just
> > before sleeping.
>
> Maybe a hook is not such a bad idea after all.
But then how would platforms where these events come from the
window-system call that hook? We'd need two different mechanisms for
the same feature, and two different ways of calling user-defined
functions when the event comes in. Or what am I missing?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Wed, 05 Feb 2025 22:38:02 GMT)
Full text and
rfc822 format available.
Message #76 received at 63620 <at> debbugs.gnu.org (full text, mbox):
>> Maybe a hook is not such a bad idea after all.
> But then how would platforms where these events come from the
> window-system call that hook?
I don't understand the question: why would those not be ale to run the
hook? If it's because it's in a separate UI thread, they can push to
`pending_funcalls`, or in the worst case they can add an event into the
event queue and then use `special-event-map` to run an ad-hoc function
which runs the hook.
Of course, we could similarly make the D-bus code manually do
(lookup-key special-event-map [sleep-event])
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Thu, 06 Feb 2025 01:45:02 GMT)
Full text and
rfc822 format available.
Message #79 received at 63620 <at> debbugs.gnu.org (full text, mbox):
>>>>> "SM" == Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>>> Maybe a hook is not such a bad idea after all.
>> But then how would platforms where these events come from the
>> window-system call that hook?
SM> I don't understand the question: why would those not be ale to
SM> run the hook? If it's because it's in a separate UI thread,
SM> they can push to `pending_funcalls`, or in the worst case they
SM> can add an event into the event queue and then use
SM> `special-event-map` to run an ad-hoc function which runs the
SM> hook.
I remain open to other ideas, but it seems to me that the most
straightforward is to allow systems to add a sleep-event into the event
queue. My original code installed a callback function to run the hooks
when a state change is detected. So this same function can be installed
into special-event-map and the behavior on all systems is the same.
I've modified the code a bit---I've made the handler function
configurable with a defcustom and set it by default to the function that
just runs the hooks. But the same handler will be used on both
sleep-events and dbus detection. The only difference is that if the
system supports dbus, dbus detection of state changes will be used,
while in other cases sleep-events will trigger the handler.
;;; sleep.el --- run hooks on device sleep and wake -*- lexical-binding:t -*-
;; Copyright (C) 2025 Free Software Foundation, Inc.
;; Author: Andrew Cohen <>
;; Maintainer: emacs-devel <at> gnu.org
;; Keywords:
;; This file is part of GNU Emacs.
;; GNU Emacs is free software: you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.
;; GNU Emacs is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
;; GNU General Public License for more details.
;; You should have received a copy of the GNU General Public License
;; along with GNU Emacs. If not, see <https://www.gnu.org/licenses/>.
;;; Commentary:
;;; This global minor mode enables evaluating code when the device
;;; running Emacs enters or leaves the sleep state. The hooks
;;; `sleep-sleep-hook' and `sleep-wake-hook' are run when the system
;;; detects that it is going to sleep or waking up. Currently only a
;;; D-Bus interface to detect sleep state change is implemented.
;;; Code:
(require 'dbus)
(defgroup sleep nil
"Run hooks on device entering/leaving the sleep state."
:group 'hardware)
(defcustom sleep-handler-function 'handle-sleep-event
"Function called on device sleep state change.
The function takes a single boolean argument (t for sleep and nil for
wake). The default function just runs the sleep and wake hooks."
:group 'sleep
:type 'function)
(defcustom sleep-sleep-hook nil
"Hook to run on device entering sleep."
:group 'sleep
:type 'hook)
(defcustom sleep-wake-hook nil
"Hook to run on device leaving sleep."
:group 'sleep
:type 'hook)
(defvar sleep-dbus-registration-object nil
"Object returned from `dbus-register-signal'.
This is recorded so that the signal may be unregistered.")
(defun sleep-dbus-detection (mode)
"Enable D-Bus detection of device sleep/wake state change.
When enabled run `sleep-handler-function' when a state change is
detected. Disable detection if MODE is nil."
(if mode
(unless sleep-dbus-registration-object
(setq sleep-dbus-registration-object
(dbus-register-signal :system
"org.freedesktop.login1"
"/org/freedesktop/login1"
"org.freedesktop.login1.Manager"
"PrepareForSleep"
sleep-handler-function)))
(condition-case nil
(progn
(ignore-error (dbus-error wrong-type-argument)
(dbus-unregister-object
sleep-dbus-registration-object))
(setq sleep-dbus-registration-object nil))
(wrong-type-argument nil))))
(defun handle-sleep-event (sleep-wake)
"Handler to execute sleep and wake functions.
SLEEP-WAKE is t on sleeping and nil on waking."
(ignore-errors
(if sleep-wake
(run-hooks 'sleep-sleep-hook)
(run-hooks 'sleep-wake-hook))))
;;;###autoload
(define-minor-mode sleep-wake-mode
"Toggle sleep/wake detection.
With `sleep-wake-mode' enabled, the hooks `sleep-sleep-hook' and
`sleep-wake-hook' will be executed when the device enters or leaves the
sleep state. This is currently only available on systems that support
D-Bus detection of sleep state changes."
:global t
:group 'sleep
(cond
((and (featurep 'dbusbind)
(member "org.freedesktop.login1"
(dbus-list-activatable-names :system)))
(sleep-dbus-detection sleep-wake-mode))
(t
(if sleep-wake-mode
(define-key special-event-map [sleep-event] sleep-handler-function)
(define-key special-event-map [sleep-event] 'ignore)))))
(provide 'sleep)
;;; sleep.el ends here
--
Andrew Cohen
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Thu, 06 Feb 2025 02:09:01 GMT)
Full text and
rfc822 format available.
Message #82 received at 63620 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
If someone builds without dbus, say on macOS, does this approach work
without dbus?
On Wed, Feb 5, 2025 at 8:44 PM Andrew Cohen <acohen <at> ust.hk> wrote:
> >>>>> "SM" == Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>
> >>> Maybe a hook is not such a bad idea after all.
> >> But then how would platforms where these events come from the
> >> window-system call that hook?
>
> SM> I don't understand the question: why would those not be ale to
> SM> run the hook? If it's because it's in a separate UI thread,
> SM> they can push to `pending_funcalls`, or in the worst case they
> SM> can add an event into the event queue and then use
> SM> `special-event-map` to run an ad-hoc function which runs the
> SM> hook.
>
> I remain open to other ideas, but it seems to me that the most
> straightforward is to allow systems to add a sleep-event into the event
> queue. My original code installed a callback function to run the hooks
> when a state change is detected. So this same function can be installed
> into special-event-map and the behavior on all systems is the same.
>
> I've modified the code a bit---I've made the handler function
> configurable with a defcustom and set it by default to the function that
> just runs the hooks. But the same handler will be used on both
> sleep-events and dbus detection. The only difference is that if the
> system supports dbus, dbus detection of state changes will be used,
> while in other cases sleep-events will trigger the handler.
>
> ;;; sleep.el --- run hooks on device sleep and wake -*- lexical-binding:t
> -*-
>
> ;; Copyright (C) 2025 Free Software Foundation, Inc.
>
> ;; Author: Andrew Cohen <>
> ;; Maintainer: emacs-devel <at> gnu.org
> ;; Keywords:
>
> ;; This file is part of GNU Emacs.
>
> ;; GNU Emacs is free software: you can redistribute it and/or modify
> ;; it under the terms of the GNU General Public License as published by
> ;; the Free Software Foundation, either version 3 of the License, or
> ;; (at your option) any later version.
>
> ;; GNU Emacs is distributed in the hope that it will be useful,
> ;; but WITHOUT ANY WARRANTY; without even the implied warranty of
> ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> ;; GNU General Public License for more details.
>
> ;; You should have received a copy of the GNU General Public License
> ;; along with GNU Emacs. If not, see <https://www.gnu.org/licenses/>.
>
> ;;; Commentary:
>
> ;;; This global minor mode enables evaluating code when the device
> ;;; running Emacs enters or leaves the sleep state. The hooks
> ;;; `sleep-sleep-hook' and `sleep-wake-hook' are run when the system
> ;;; detects that it is going to sleep or waking up. Currently only a
> ;;; D-Bus interface to detect sleep state change is implemented.
>
> ;;; Code:
>
> (require 'dbus)
>
> (defgroup sleep nil
> "Run hooks on device entering/leaving the sleep state."
> :group 'hardware)
>
> (defcustom sleep-handler-function 'handle-sleep-event
> "Function called on device sleep state change.
> The function takes a single boolean argument (t for sleep and nil for
> wake). The default function just runs the sleep and wake hooks."
> :group 'sleep
> :type 'function)
>
> (defcustom sleep-sleep-hook nil
> "Hook to run on device entering sleep."
> :group 'sleep
> :type 'hook)
>
> (defcustom sleep-wake-hook nil
> "Hook to run on device leaving sleep."
> :group 'sleep
> :type 'hook)
>
> (defvar sleep-dbus-registration-object nil
> "Object returned from `dbus-register-signal'.
> This is recorded so that the signal may be unregistered.")
>
> (defun sleep-dbus-detection (mode)
> "Enable D-Bus detection of device sleep/wake state change.
> When enabled run `sleep-handler-function' when a state change is
> detected. Disable detection if MODE is nil."
> (if mode
> (unless sleep-dbus-registration-object
> (setq sleep-dbus-registration-object
> (dbus-register-signal :system
> "org.freedesktop.login1"
> "/org/freedesktop/login1"
> "org.freedesktop.login1.Manager"
> "PrepareForSleep"
> sleep-handler-function)))
> (condition-case nil
> (progn
> (ignore-error (dbus-error wrong-type-argument)
> (dbus-unregister-object
> sleep-dbus-registration-object))
> (setq sleep-dbus-registration-object nil))
> (wrong-type-argument nil))))
>
> (defun handle-sleep-event (sleep-wake)
> "Handler to execute sleep and wake functions.
> SLEEP-WAKE is t on sleeping and nil on waking."
> (ignore-errors
> (if sleep-wake
> (run-hooks 'sleep-sleep-hook)
> (run-hooks 'sleep-wake-hook))))
>
> ;;;###autoload
> (define-minor-mode sleep-wake-mode
> "Toggle sleep/wake detection.
>
> With `sleep-wake-mode' enabled, the hooks `sleep-sleep-hook' and
> `sleep-wake-hook' will be executed when the device enters or leaves the
> sleep state. This is currently only available on systems that support
> D-Bus detection of sleep state changes."
> :global t
> :group 'sleep
> (cond
> ((and (featurep 'dbusbind)
> (member "org.freedesktop.login1"
> (dbus-list-activatable-names :system)))
> (sleep-dbus-detection sleep-wake-mode))
> (t
> (if sleep-wake-mode
> (define-key special-event-map [sleep-event] sleep-handler-function)
> (define-key special-event-map [sleep-event] 'ignore)))))
>
> (provide 'sleep)
> ;;; sleep.el ends here
>
>
> --
> Andrew Cohen
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Thu, 06 Feb 2025 02:22:02 GMT)
Full text and
rfc822 format available.
Message #85 received at 63620 <at> debbugs.gnu.org (full text, mbox):
>>>>> "SM" == Ship Mints <shipmints <at> gmail.com> writes:
SM> If someone builds without dbus, say on macOS, does this approach
SM> work without dbus?
This assumes that detection of sleep/wake state changes will be added to
the C source (as you offered to implement for NS :)). The idea is that
you add code to detect the change at the OS level, and then create an
event of type sleep-event with an argument of t for sleep and nil for
wake. The lisp package detects the sleep-event and runs the appropriate
code.
It won't work quite yet (this was just showing the concept) since the C
code has to be written, and the handler function needs to accept either
an event (a cons) or a boolean. But if everyone thinks this is a valid
approach we can take care of this.
Best,
Andy
--
Andrew Cohen
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Thu, 06 Feb 2025 02:27:02 GMT)
Full text and
rfc822 format available.
Message #88 received at 63620 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I didn't read the code yet so I'm glad this approach doesn't depend on
dbus.
I will happily work on the NS event generation. I can prototype any time
we're ready.
On Wed, Feb 5, 2025 at 21:20 Andrew Cohen <acohen <at> ust.hk> wrote:
> >>>>> "SM" == Ship Mints <shipmints <at> gmail.com> writes:
>
> SM> If someone builds without dbus, say on macOS, does this approach
> SM> work without dbus?
>
> This assumes that detection of sleep/wake state changes will be added to
> the C source (as you offered to implement for NS :)). The idea is that
> you add code to detect the change at the OS level, and then create an
> event of type sleep-event with an argument of t for sleep and nil for
> wake. The lisp package detects the sleep-event and runs the appropriate
> code.
>
> It won't work quite yet (this was just showing the concept) since the C
> code has to be written, and the handler function needs to accept either
> an event (a cons) or a boolean. But if everyone thinks this is a valid
> approach we can take care of this.
>
> Best,
> Andy
> --
> Andrew Cohen
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Thu, 06 Feb 2025 05:21:01 GMT)
Full text and
rfc822 format available.
Message #91 received at 63620 <at> debbugs.gnu.org (full text, mbox):
> The idea is that you add code to detect the change at the OS level,
> and then create an event of type sleep-event with an argument of t for
> sleep and nil for wake. The lisp package detects the sleep-event and
> runs the appropriate code.
BTW: I understand what a "wake" event means, but what about
a "sleep" event? I mean: how can we receive this event before we wake
up again? Or does it mean that we're about to sleep? If so what do we
know about when we'll sleep? Can we influence (e.g. delay) it?
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Thu, 06 Feb 2025 06:01:01 GMT)
Full text and
rfc822 format available.
Message #94 received at 63620 <at> debbugs.gnu.org (full text, mbox):
>>>>> "SM" == Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
[...]
SM> BTW: I understand what a "wake" event means, but what about a
SM> "sleep" event? I mean: how can we receive this event before we
SM> wake up again? Or does it mean that we're about to sleep?
The events that I am detecting with D-Bus are actually part of logind, a
tiny daemon that manages user logins in various ways. The process
monitors the status of a variety of hardware components (such as the
state of the lid, power, etc), and is responsible for managing
suspension and hibernation. I think that logind, part of
freedesktop.org, is pretty universal on gnu/linux.
The signal I am accessing, PrepareForSleep, is sent right before the
systems enters suspend/hibernate (with argument True), and right after
the system leaves suspend/hibernate (with argument False).
SM> If so what do we know about when we'll sleep?
I don't think there is a guarantee how much time remains before the
sleep state is fully realized. However I've been using this for a couple
of years and have never had a failure to run the hooks to completion.
SM> Can we influence (e.g. delay) it?
logind has a method to inhibit sleeping (exposed through D-Bus), which
can be used to create an inhibition lock, preventing sleep until the
lock is released. It would be ideal to implement this around running the
hooks to ensure that all the Emacs code completes before finishing
sleep. It shouldn't be hard, I just haven't found it necessary. I'll
take a look. And its probably important to have some well-designed API
for this as well.
The real question is what to do on systems that don't use logind. That
will depend on what kind of information is available and how we can
control things. Inevitably this means that we will have a fair amount of
system-specific code in the package.
Best,
Andy
PS:
In trying to understand `unread-command-events' and 'special-event-map'
I came across this bit in bindings.el:
;; FIXME: Do those 3 events really ever reach the global-map ?
;; It seems that they can't because they're handled via
;; special-event-map which is used at very low-level. -stef
(global-set-key [delete-frame] 'handle-delete-frame)
(global-set-key [iconify-frame] 'ignore)
(global-set-key [make-frame-visible] 'ignore)
So I think the answer to the question is "yes, provided someone puts the
event on unread-command-events" where it won't be handled first by
special-event-map. This is why I found that I could inject these special
events onto unread-command-events and have them trigger a callback, but
not the others.
--
Andrew Cohen
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Thu, 06 Feb 2025 07:33:01 GMT)
Full text and
rfc822 format available.
Message #97 received at 63620 <at> debbugs.gnu.org (full text, mbox):
>>>>> "SM" == Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
[...]
SM> so what do we know about when we'll sleep? Can we influence
SM> (e.g. delay) it?
So I can make it work easily for the D-Bus backend, with one minor
issue. The D-Bus interface returns a file descriptor (a natural number)
for the FIFO that is inhibiting sleep. To allow sleep I have to close
this. How can I do that from Emacs?
Best,
Andy
--
Andrew Cohen
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Thu, 06 Feb 2025 08:27:02 GMT)
Full text and
rfc822 format available.
Message #100 received at 63620 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: acohen <at> ust.hk, 63620 <at> debbugs.gnu.org, michael.albinus <at> gmx.de
> Date: Wed, 05 Feb 2025 17:37:20 -0500
>
> >> Maybe a hook is not such a bad idea after all.
> > But then how would platforms where these events come from the
> > window-system call that hook?
>
> I don't understand the question:
It seems you understood it well enough to answer it ;-)
> why would those not be ale to run the
> hook? If it's because it's in a separate UI thread, they can push to
> `pending_funcalls`, or in the worst case they can add an event into the
> event queue and then use `special-event-map` to run an ad-hoc function
> which runs the hook.
>
> Of course, we could similarly make the D-bus code manually do
> (lookup-key special-event-map [sleep-event])
Thanks, so which of these solutions would you recommend as the
cleanest and the most convenient/extensible one?
Michael, do you have any opinions or comments about these
possibilities, from the D-Bus support POV?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Thu, 06 Feb 2025 10:57:02 GMT)
Full text and
rfc822 format available.
Message #103 received at 63620 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On macOS, the receiver of a "will sleep" notification can delay sleep for
some time. There's also a message when the screen is put to sleep but not
the OS that might have some utility.
On Thu, Feb 6, 2025 at 12:20 AM Stefan Monnier <monnier <at> iro.umontreal.ca>
wrote:
> > The idea is that you add code to detect the change at the OS level,
> > and then create an event of type sleep-event with an argument of t for
> > sleep and nil for wake. The lisp package detects the sleep-event and
> > runs the appropriate code.
>
> BTW: I understand what a "wake" event means, but what about
> a "sleep" event? I mean: how can we receive this event before we wake
> up again? Or does it mean that we're about to sleep? If so what do we
> know about when we'll sleep? Can we influence (e.g. delay) it?
>
>
> Stefan
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Thu, 06 Feb 2025 11:57:02 GMT)
Full text and
rfc822 format available.
Message #106 received at 63620 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi Eli,
>> why would those not be ale to run the
>> hook? If it's because it's in a separate UI thread, they can push to
>> `pending_funcalls`, or in the worst case they can add an event into the
>> event queue and then use `special-event-map` to run an ad-hoc function
>> which runs the hook.
>>
>> Of course, we could similarly make the D-bus code manually do
>> (lookup-key special-event-map [sleep-event])
>
> Thanks, so which of these solutions would you recommend as the
> cleanest and the most convenient/extensible one?
>
> Michael, do you have any opinions or comments about these
> possibilities, from the D-Bus support POV?
I'm against to touch the D-Bus code because of this. Unneeded
dependency.
I've assembled a POC patch (appended), which adds the sleep-event
special event to special-event-map, and which adds a new function
insert-special-event, all on C level. With this, I'm able to eval in the
*scratch* buffer
--8<---------------cut here---------------start------------->8---
(defun sleep-handle-event (event)
(declare (completion ignore))
(interactive "e")
(message "Event arrived: %S" event))
(insert-special-event '(sleep-event t))
--8<---------------cut here---------------end--------------->8---
insert-special-event is not restricted to the sleep-event event, but
shall support all special events, finally.
Comments?
Best regards, Michael.
[Message part 2 (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Thu, 06 Feb 2025 12:21:01 GMT)
Full text and
rfc822 format available.
Message #109 received at submit <at> debbugs.gnu.org (full text, mbox):
>>>>> "MA" == Bug reports for GNU Emacs, the Swiss army knife of text editors <Michael> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Thu, 06 Feb 2025 12:21:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Thu, 06 Feb 2025 12:27:02 GMT)
Full text and
rfc822 format available.
Message #115 received at 63620 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <acohen <at> ust.hk> wrote:
> >>>>> "MA" == Bug reports for GNU Emacs, the Swiss army knife of text
> editors <Michael> 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
>
>
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Thu, 06 Feb 2025 13:03:02 GMT)
Full text and
rfc822 format available.
Message #118 received at 63620 <at> debbugs.gnu.org (full text, mbox):
>>>>> "SM" == Ship Mints <shipmints <at> gmail.com> writes:
SM> The API on macOS would expose a pair of C functions to lisp, one
SM> would inhibit sleep, perhaps returning an opaque "cookie", the
SM> second to revoke the inhibition. The same API can be used to
SM> prevent macOS from ever sleeping, if the user wanted that.
Great!
So the idea now is:
Turning on sleep-wake-mode:
0. If on a system with D-Bus and logind, we register a signal for
PrepareForSleep with a handler that generates a synthetic sleep-event on
state change using Michael's recent insert-special-event.
1. Install 'sleep-event-handler on the special-event-map for
[sleep-event].
'sleep-event-handler will inhibit sleep (with whatever method is
appropriate for the system); run the function sleep-handler-function
which is a defcustom defaulting to running the hooks; release the
inhibition.
2. disabling sleep-wake-mode removes 'sleep-event-handler from the
keymap and replaces it with 'ignore.
(alternatively we could ask each system to expose a lisp function or
variable to turn on and off the generation of sleep-events)
Best,
Andy
--
Andrew Cohen
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Thu, 06 Feb 2025 13:10:01 GMT)
Full text and
rfc822 format available.
Message #121 received at 63620 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I prefer using a mode, it seems more idiomatic. Shall this use
cl-defgeneric in sleep-wake-mode that each system can specialize?
On Thu, Feb 6, 2025 at 8:02 AM Andrew Cohen <acohen <at> ust.hk> wrote:
> >>>>> "SM" == Ship Mints <shipmints <at> gmail.com> writes:
>
> SM> The API on macOS would expose a pair of C functions to lisp, one
> SM> would inhibit sleep, perhaps returning an opaque "cookie", the
> SM> second to revoke the inhibition. The same API can be used to
> SM> prevent macOS from ever sleeping, if the user wanted that.
>
> Great!
>
> So the idea now is:
>
> Turning on sleep-wake-mode:
>
> 0. If on a system with D-Bus and logind, we register a signal for
> PrepareForSleep with a handler that generates a synthetic sleep-event on
> state change using Michael's recent insert-special-event.
>
> 1. Install 'sleep-event-handler on the special-event-map for
> [sleep-event].
>
> 'sleep-event-handler will inhibit sleep (with whatever method is
> appropriate for the system); run the function sleep-handler-function
> which is a defcustom defaulting to running the hooks; release the
> inhibition.
>
> 2. disabling sleep-wake-mode removes 'sleep-event-handler from the
> keymap and replaces it with 'ignore.
>
> (alternatively we could ask each system to expose a lisp function or
> variable to turn on and off the generation of sleep-events)
>
> Best,
> Andy
>
>
> --
> Andrew Cohen
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Thu, 06 Feb 2025 14:06:02 GMT)
Full text and
rfc822 format available.
Message #124 received at submit <at> debbugs.gnu.org (full text, mbox):
Andrew Cohen <acohen <at> ust.hk> writes:
Hi Andrew,
> 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.
Good idea, I change the patch accordingly.
> 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.
I haven't checked this yet. We will do it once the special-event based
approach is accepted.
> Best,
> Andy
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Thu, 06 Feb 2025 14:06:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Thu, 06 Feb 2025 14:10:01 GMT)
Full text and
rfc822 format available.
Message #130 received at 63620 <at> debbugs.gnu.org (full text, mbox):
Ship Mints <shipmints <at> gmail.com> writes:
Hi Ship,
> 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.
Why that? If we have the special event sleep-event, you can call
kbd_buffer_store_event directly in your C source.
The arguments for the sleep-event can be extended as we like, as API.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Thu, 06 Feb 2025 14:14:01 GMT)
Full text and
rfc822 format available.
Message #133 received at 63620 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
The flow, as I understand it looks like it will be:
1 OS reports about to sleep
2 C code posts an event
3 sleep-wake-mode processes the event
3a Tell the OS to prevent sleep (has to be done in C)
3b Call hooks
3c Tell the OS it's now okay to sleep (ditto in C)
It's 3a and 3c that I was referring to.
On Thu, Feb 6, 2025 at 9:09 AM Michael Albinus <michael.albinus <at> gmx.de>
wrote:
> Ship Mints <shipmints <at> gmail.com> writes:
>
> Hi Ship,
>
> > 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.
>
> Why that? If we have the special event sleep-event, you can call
> kbd_buffer_store_event directly in your C source.
>
> The arguments for the sleep-event can be extended as we like, as API.
>
> Best regards, Michael.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Thu, 06 Feb 2025 14:54:02 GMT)
Full text and
rfc822 format available.
Message #136 received at 63620 <at> debbugs.gnu.org (full text, mbox):
Ship Mints <shipmints <at> gmail.com> writes:
Hi Ship,
> The flow, as I understand it looks like it will be:
>
> 1 OS reports about to sleep
> 2 C code posts an event
> 3 sleep-wake-mode processes the event
> 3a Tell the OS to prevent sleep (has to be done in C)
> 3b Call hooks
> 3c Tell the OS it's now okay to sleep (ditto in C)
>
> It's 3a and 3c that I was referring to.
Thanks, it wasn't clear to me in your message.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Thu, 06 Feb 2025 15:20:01 GMT)
Full text and
rfc822 format available.
Message #139 received at 63620 <at> debbugs.gnu.org (full text, mbox):
> From: Andrew Cohen <acohen <at> ust.hk>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Michael Albinus <michael.albinus <at> gmx.de>,
> 63620 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
> Date: Thu, 06 Feb 2025 20:20:18 +0800
>
> 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.
What is the semantics of this? If the user closes the lid of the
laptop, and that was defined to put the system to sleep, does such
"inhibiting" mean the system will not sleep? If so, I'm not sure this
is supported. Or do you mean to delay sleep which is triggered by
prolonged enough lack of activity?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Thu, 06 Feb 2025 15:30:02 GMT)
Full text and
rfc822 format available.
Message #142 received at 63620 <at> debbugs.gnu.org (full text, mbox):
> From: Ship Mints <shipmints <at> gmail.com>
> Date: Thu, 6 Feb 2025 07:24:37 -0500
> Cc: 63620 <at> debbugs.gnu.org, eliz <at> gnu.org, michael.albinus <at> gmx.de,
> monnier <at> iro.umontreal.ca
>
> 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.
Why would this have to be exposed to Lisp? We want to make sure the
system doesn't go to sleep until after the function invoked by the
"about to go to sleep" event completes its job and exits, and for that
all we need is to revoke the inhibition once the function exits, no?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Thu, 06 Feb 2025 15:30:03 GMT)
Full text and
rfc822 format available.
Message #145 received at 63620 <at> debbugs.gnu.org (full text, mbox):
> Thanks, so which of these solutions would you recommend as the
> cleanest and the most convenient/extensible one?
For the "wake", we could make it into an event, but for the "sleep" part
we can't really push this to the event queue because we need to process
it promptly (the system is waiting for an answer).
So I'd go with the hook.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Thu, 06 Feb 2025 15:31:02 GMT)
Full text and
rfc822 format available.
Message #148 received at 63620 <at> debbugs.gnu.org (full text, mbox):
> insert-special-event is not restricted to the sleep-event event, but
> shall support all special events, finally.
FWIW, that sounds like a useful primitive.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Thu, 06 Feb 2025 15:37:02 GMT)
Full text and
rfc822 format available.
Message #151 received at 63620 <at> debbugs.gnu.org (full text, mbox):
> What is the semantics of this? If the user closes the lid of the
> laptop, and that was defined to put the system to sleep, does such
> "inhibiting" mean the system will not sleep? If so, I'm not sure this
> is supported.
Don't know about "supported", but failing to sleep when the laptop is
closed can be a major problem (I only experienced the milder versions,
like finding my laptop with an empty battery, or my backpack all dirty
with melted chocolate, but overheating can be a serious issue).
[ Of course, it can also be useful, when the laptop is docked into
a keyboard+screen station, or when you want to use it as a headless
server. ]
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Thu, 06 Feb 2025 15:37:03 GMT)
Full text and
rfc822 format available.
Message #154 received at 63620 <at> debbugs.gnu.org (full text, mbox):
>>>>> "EZ" == Eli Zaretskii <eliz <at> gnu.org> writes:
[...]
EZ> What is the semantics of this? If the user closes the lid of
EZ> the laptop, and that was defined to put the system to sleep,
EZ> does such "inhibiting" mean the system will not sleep? If so,
EZ> I'm not sure this is supported. Or do you mean to delay sleep
EZ> which is triggered by prolonged enough lack of activity?
The former. Here is how it works for logind (which is common for
gnu/linux desktops):
logind, as part of the desktop system, takes responsibility for sleep
initiated through the desktop: that is, through a lack of activity, an
explicit hibernate command (maybe a keypress or a menu item) or through
a lid switch, for example. When a sleep request is initiated this way,
it is announced through D-Bus (the PrepareForSleep signal); D-Bus also
has methods that can control the behavior. An "Inhibit" method can be
called which inhibits the sleep process, even if the lid is now closed,
for example. (This inhibition can just be a delay, or it can be a full
block depending on the parameters passed to "Inhibit"); as long as the
block is in place the system will not sleep. The "Inhibit" method
returns a file descriptor, and the block remains in force until the file
descriptor is closed.
It is, of course, possible to trigger hibernation outside of the desktop
system (directly to the kernel, for example), and this is not controlled
through D-Bus.
My daily routine involves a laptop moving from home to office, and I
rarely log out of the desktop or shutdown. So I typically just shut the
lid which triggers hibernation, and rely on sleep-wake-mode to manage
gnus network connections and my vpn. I had never bothered inhibiting the
sleep since Emacs was always fast enough to complete in time, but the
right thing is certainly to call the "Inhibit" method. Other systems are
likely different.
Best,
Andy
--
Andrew Cohen
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Thu, 06 Feb 2025 15:43:01 GMT)
Full text and
rfc822 format available.
Message #157 received at 63620 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Thu, Feb 6, 2025 at 10:29 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Ship Mints <shipmints <at> gmail.com>
> > Date: Thu, 6 Feb 2025 07:24:37 -0500
> > Cc: 63620 <at> debbugs.gnu.org, eliz <at> gnu.org, michael.albinus <at> gmx.de,
> > monnier <at> iro.umontreal.ca
> >
> > 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.
>
> Why would this have to be exposed to Lisp? We want to make sure the
> system doesn't go to sleep until after the function invoked by the
> "about to go to sleep" event completes its job and exits, and for that
> all we need is to revoke the inhibition once the function exits, no?
>
That's right. The revocation on macOS requires calling an objective-c API
to relinquish the inhibition.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Thu, 06 Feb 2025 15:44:02 GMT)
Full text and
rfc822 format available.
Message #160 received at 63620 <at> debbugs.gnu.org (full text, mbox):
>>>>> "SM" == Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> What is the semantics of this? If the user closes the lid of the
>> laptop, and that was defined to put the system to sleep, does
>> such "inhibiting" mean the system will not sleep? If so, I'm not
>> sure this is supported.
SM> Don't know about "supported", but failing to sleep when the
SM> laptop is closed can be a major problem (I only experienced the
SM> milder versions, like finding my laptop with an empty battery,
SM> or my backpack all dirty with melted chocolate, but overheating
SM> can be a serious issue).
The "Inhibit" method I am using allows a delay rather than a total
block. You can specify a time (default I think is 5 seconds) after which
the sleep will proceed (or you can remove the delay earlier). So your
chocolate is safe (at least from melting).
--
Andrew Cohen
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Thu, 06 Feb 2025 15:45:03 GMT)
Full text and
rfc822 format available.
Message #163 received at 63620 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
macOS has an annoying feature that will wake the computer periodically to
check shite like email and messages and then go back to sleep. I do not
know if the notifications we're interested in are invoked by this default
behavior. I've disabled mine to avoid burning the battery with the lid
closed.
On Thu, Feb 6, 2025 at 10:37 AM Stefan Monnier via Bug reports for GNU
Emacs, the Swiss army knife of text editors <bug-gnu-emacs <at> gnu.org> wrote:
> > What is the semantics of this? If the user closes the lid of the
> > laptop, and that was defined to put the system to sleep, does such
> > "inhibiting" mean the system will not sleep? If so, I'm not sure this
> > is supported.
>
> Don't know about "supported", but failing to sleep when the laptop is
> closed can be a major problem (I only experienced the milder versions,
> like finding my laptop with an empty battery, or my backpack all dirty
> with melted chocolate, but overheating can be a serious issue).
>
> [ Of course, it can also be useful, when the laptop is docked into
> a keyboard+screen station, or when you want to use it as a headless
> server. ]
>
>
> Stefan
>
>
>
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Thu, 06 Feb 2025 15:45:03 GMT)
Full text and
rfc822 format available.
Message #166 received at 63620 <at> debbugs.gnu.org (full text, mbox):
> From: Ship Mints <shipmints <at> gmail.com>
> Date: Thu, 6 Feb 2025 08:07:44 -0500
> Cc: 63620 <at> debbugs.gnu.org, eliz <at> gnu.org, michael.albinus <at> gmx.de,
> monnier <at> iro.umontreal.ca
>
> I prefer using a mode, it seems more idiomatic. Shall this use cl-defgeneric in sleep-wake-mode that each
> system can specialize?
Are there differences on the Lisp level between the systems?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Thu, 06 Feb 2025 15:48:02 GMT)
Full text and
rfc822 format available.
Message #169 received at 63620 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Only insofar as the C-level API calls are different and that the mechanism
may have an impedance mismatches. For example, I do not think on macOS
there is a way to describe a delay as Andrew suggests there is on
dbus/logind/systemd. The only API I'm aware of is one where you tell the OS
that the "user is busy" and then tell it the user is not busy. However, the
documentation for the "will sleep" notification does say one can delay in
the handler but is otherwise silent on how to do that and I've found no
information. I'll have to contact Apple to see how to do this, if it's
real. It could be vestigial documentation.
On Thu, Feb 6, 2025 at 10:44 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Ship Mints <shipmints <at> gmail.com>
> > Date: Thu, 6 Feb 2025 08:07:44 -0500
> > Cc: 63620 <at> debbugs.gnu.org, eliz <at> gnu.org, michael.albinus <at> gmx.de,
> > monnier <at> iro.umontreal.ca
> >
> > I prefer using a mode, it seems more idiomatic. Shall this use
> cl-defgeneric in sleep-wake-mode that each
> > system can specialize?
>
> Are there differences on the Lisp level between the systems?
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Thu, 06 Feb 2025 15:59:01 GMT)
Full text and
rfc822 format available.
Message #172 received at 63620 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: acohen <at> ust.hk, 63620 <at> debbugs.gnu.org, michael.albinus <at> gmx.de
> Date: Thu, 06 Feb 2025 10:29:27 -0500
>
> > Thanks, so which of these solutions would you recommend as the
> > cleanest and the most convenient/extensible one?
>
> For the "wake", we could make it into an event, but for the "sleep" part
> we can't really push this to the event queue because we need to process
> it promptly (the system is waiting for an answer).
AFAIK, this is not a problem, because the system will wait for
programs to become idle anyway.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Thu, 06 Feb 2025 16:07:02 GMT)
Full text and
rfc822 format available.
Message #175 received at 63620 <at> debbugs.gnu.org (full text, mbox):
> From: Ship Mints <shipmints <at> gmail.com>
> Date: Thu, 6 Feb 2025 10:42:02 -0500
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Andrew Cohen <acohen <at> ust.hk>, 63620 <at> debbugs.gnu.org,
> michael.albinus <at> gmx.de
>
> macOS has an annoying feature that will wake the computer periodically to check shite like email and
> messages and then go back to sleep. I do not know if the notifications we're interested in are invoked by this
> default behavior. I've disabled mine to avoid burning the battery with the lid closed.
If the system wakes from sleep, it shouldn't matter to Emacs why it
wakes. If it then goes back to sleep, the sleep handler will be
reinvoked; if it doesn't, it won't.
So I'm not sure we should worry about this. If the user doesn't want
his/her system to be awoken by these conditions, he/she should
configure the system appropriately, like you did.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Fri, 07 Feb 2025 07:15:02 GMT)
Full text and
rfc822 format available.
Message #178 received at 63620 <at> debbugs.gnu.org (full text, mbox):
>>>>> "AC" == Andrew Cohen <acohen <at> ust.hk> writes:
>>>>> "SM" == Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
AC> [...]
SM> so what do we know about when we'll sleep? Can we influence
SM> (e.g. delay) it?
AC> So I can make it work easily for the D-Bus backend, with one
AC> minor issue. The D-Bus interface returns a file descriptor (a
AC> natural number) for the FIFO that is inhibiting sleep. To allow
AC> sleep I have to close this. How can I do that from Emacs?
Just an update:
I have a more or less complete implementation using Michael's
modifications for `insert-special-event'. A sleep-event triggers a
function that manages blocking/unblocking sleep and running the
appropriate hooks. This will work on any system that generates the
sleep-event (the blocking/unblocking routines are D-Bus specific, but
once we know what this looks like on other systems we can dispatch
appropriately). The D-Bus handler just inserts a synthetic sleep-event
when it receives a PrepareForSleep notification. This is what I have
been running for today with no problems.
I spent some time looking over the documentation and the general
recommendations for dealing with sleep notifications. The recommendation
(from systemd/logind) is that any application that needs to do something
prior to sleep should monitor for sleep notifications and install the
block preventing sleep at the time that monitoring starts. When a
notification of sleep is received the application should complete its
work and then remove the block. After waking up, the block should be
restored. This is the logic that I have implemented. (systemd allows me
to list all of the applications holding blocks. My gnome desktop
typically shows 7 or 8 applications holding blocks for sleep, including
the Network Manager, Power Manager, etc). This is slightly different
from what I was doing earlier (where the block was put in place
immediately after receiving the sleep notification---this could lead to
problems if sleep takes over before Emacs completes its
actions. Although in practice I never encountered an actual problem).
The only other thing I had to do was figure out how to close the file
descriptor that implemented the block. According to systemd/logind its
the application's responsibility to close the descriptor to release the
block. But I couldn't find any way to do this from lisp. In the end I
just exported `emacs_close' to lisp as `emacs-close-fd' and this works
fine. But maybe there is a different approach.
Best,
Andy
--
Andrew Cohen
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Fri, 07 Feb 2025 08:04:01 GMT)
Full text and
rfc822 format available.
Message #181 received at 63620 <at> debbugs.gnu.org (full text, mbox):
Andrew Cohen <acohen <at> ust.hk> writes:
Hi Andrew,
> (systemd allows me to list all of the applications holding blocks. My
> gnome desktop typically shows 7 or 8 applications holding blocks for
> sleep, including the Network Manager, Power Manager, etc)
Side note: According to org.freedesktop.login1.Manager, you could get
this information also on D-Bus level, calling method ListInhibitors.
Another idea: There are the properties Docked, LidClosed and
OnExternalPower. Perhaps you could check them in your sleep-handler, and
start different actions depending on their value.
> Best,
> Andy
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Fri, 07 Feb 2025 08:21:02 GMT)
Full text and
rfc822 format available.
Message #184 received at 63620 <at> debbugs.gnu.org (full text, mbox):
>>>>> "MA" == Michael Albinus <michael.albinus <at> gmx.de> writes:
MA> Andrew Cohen <acohen <at> ust.hk> writes: Hi Andrew,
>> (systemd allows me to list all of the applications holding
>> blocks. My gnome desktop typically shows 7 or 8 applications
>> holding blocks for sleep, including the Network Manager, Power
>> Manager, etc)
MA> Side note: According to org.freedesktop.login1.Manager, you
MA> could get this information also on D-Bus level, calling method
MA> ListInhibitors.
Yes, thanks. I was just using this for testing to see if I was
understanding the logic.
MA> Another idea: There are the properties Docked, LidClosed and
MA> OnExternalPower. Perhaps you could check them in your
MA> sleep-handler, and start different actions depending on their
MA> value.
That is a good idea. We could generalize the mode to handle a variety of
things other than sleep. Maybe we should use a new event category
(<system-event> or something) rather than sleep-event. This general
event can contain actions for sleep, docked, lidclosed, etc. And we
provide a mode for system-event, with sleep just one of the actions. For
D-Bus, this becomes pretty trivial---we just inject all the events we
are interested into system-event and have an appropriate handler.
I must say, I hadn't fully appreciated all that can be done with
D-Bus.
Best,
Andy
--
Andrew Cohen
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Fri, 07 Feb 2025 08:31:02 GMT)
Full text and
rfc822 format available.
Message #187 received at 63620 <at> debbugs.gnu.org (full text, mbox):
Andrew Cohen <acohen <at> ust.hk> writes:
Hi Andrew,
> MA> Another idea: There are the properties Docked, LidClosed and
> MA> OnExternalPower. Perhaps you could check them in your
> MA> sleep-handler, and start different actions depending on their
> MA> value.
>
> That is a good idea. We could generalize the mode to handle a variety of
> things other than sleep. Maybe we should use a new event category
> (<system-event> or something) rather than sleep-event. This general
> event can contain actions for sleep, docked, lidclosed, etc. And we
> provide a mode for system-event, with sleep just one of the actions. For
> D-Bus, this becomes pretty trivial---we just inject all the events we
> are interested into system-event and have an appropriate handler.
Yes, that's more or less the direction I was thinking of. I'm just
polishing my patch, will push it later today. I still keep the event
name sleep-event; we can change it later to system-event. But it should
be sufficient for now, for your tests and proposed patches for review.
What I'll appreciate is, if you could write down what system-event would
be good for, and which attributes a (system-event ...) event shall
carry. However, this is rather a discussion for the emecs-devel <at> gnu.org
ML, in order to get more attention from the Emacs developers.
> I must say, I hadn't fully appreciated all that can be done with
> D-Bus.
😊
> Best,
> Andy
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Fri, 07 Feb 2025 11:10:01 GMT)
Full text and
rfc822 format available.
Message #190 received at 63620 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
Hi Andrew,
> I'm just polishing my patch, will push it later today.
Done. Your proposal to expose emacs_close to Lisp must be decided by the
maintainers.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Fri, 07 Feb 2025 11:16:02 GMT)
Full text and
rfc822 format available.
Message #193 received at 63620 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, Feb 7, 2025 at 2:14 AM Andrew Cohen <acohen <at> ust.hk> wrote:
>
> I spent some time looking over the documentation and the general
> recommendations for dealing with sleep notifications. The recommendation
> (from systemd/logind) is that any application that needs to do something
> prior to sleep should monitor for sleep notifications and install the
> block preventing sleep at the time that monitoring starts. When a
> notification of sleep is received the application should complete its
> work and then remove the block. After waking up, the block should be
> restored.
The semantics on macOS are still a bit murky to me and the API is woefully
under documented. The steps on macOS, I think, will be what we discussed
earlier where the block is put in place during sleep-request handling. I
will see if it is possible to follow the same method as gnome but it may
have to be through experimentation (that'll be super fun).
The other thing I was able to find in documentation from last decade is
that there are two kinds of sleep, kind of as you'd expect:
- Forced sleep where the user explicitly does something like closing a
laptop lid or pressing a sleep button. This kind of sleep can be briefly
delayed but not blocked by an application.
- Inactive sleep where the system sleeps on user idleness. This kind of
sleep can be both delayed and blocked.
Let's keep the potential semantics and processing differences in mind when
designing how to make this work across platforms. It may be possible to
have one system implementation emulate another but that could be cumbersome
vs. a more accommodative structure.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Fri, 07 Feb 2025 11:45:01 GMT)
Full text and
rfc822 format available.
Message #196 received at 63620 <at> debbugs.gnu.org (full text, mbox):
Feb 7, 2025 19:16:03 Ship Mints <shipmints <at> gmail.com>:
> On Fri, Feb 7, 2025 at 2:14 AM Andrew Cohen <acohen <at> ust.hk> wrote:
>>
>> I spent some time looking over the documentation and the general
>> recommendations for dealing with sleep notifications. The
>> recommendation
>> (from systemd/logind) is that any application that needs to do
>> something
>> prior to sleep should monitor for sleep notifications and install the
>> block preventing sleep at the time that monitoring starts. When a
>> notification of sleep is received the application should complete its
>> work and then remove the block. After waking up, the block should be
>> restored.
>
> The semantics on macOS are still a bit murky to me and the API is
> woefully under documented. The steps on macOS, I think, will be what we
> discussed earlier where the block is put in place during sleep-request
> handling. I will see if it is possible to follow the same method as
> gnome but it may have to be through experimentation (that'll be super
> fun).
>
> The other thing I was able to find in documentation from last decade is
> that there are two kinds of sleep, kind of as you'd expect:
>
> - Forced sleep where the user explicitly does something like closing a
> laptop lid or pressing a sleep button. This kind of sleep can be
> briefly delayed but not blocked by an application.
>
> - Inactive sleep where the system sleeps on user idleness. This kind of
> sleep can be both delayed and blocked.
>
> Let's keep the potential semantics and processing differences in mind
> when designing how to make this work across platforms. It may be
> possible to have one system implementation emulate another but that
> could be cumbersome vs. a more accommodative structure.
Sure. Having thought a bit more I am convinced that starting the block
before the sleep notification is the right thing, and am hopeful that
macos can accommodate it. I think that with logind putting the block on
AFTER the notification is actually not allowed (at least it seems that
way in my testing.
But I suspect we can accommodate both approaches if necessary.
Can I get any feedback about the file descriptor closure issue? From what
I can tell without exposing it in lisp the way I did I won't be able to
use blocking anyway.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Fri, 07 Feb 2025 12:09:01 GMT)
Full text and
rfc822 format available.
Message #199 received at 63620 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Do we need to consider not blocking sleep when Emacs is run in batch mode?
On Fri, Feb 7, 2025 at 6:43 AM Andrew Cohen <acohen <at> ust.hk> wrote:
> Feb 7, 2025 19:16:03 Ship Mints <shipmints <at> gmail.com>:
>
> > On Fri, Feb 7, 2025 at 2:14 AM Andrew Cohen <acohen <at> ust.hk> wrote:
> >>
> >> I spent some time looking over the documentation and the general
> >> recommendations for dealing with sleep notifications. The
> >> recommendation
> >> (from systemd/logind) is that any application that needs to do
> >> something
> >> prior to sleep should monitor for sleep notifications and install the
> >> block preventing sleep at the time that monitoring starts. When a
> >> notification of sleep is received the application should complete its
> >> work and then remove the block. After waking up, the block should be
> >> restored.
> >
> > The semantics on macOS are still a bit murky to me and the API is
> > woefully under documented. The steps on macOS, I think, will be what we
> > discussed earlier where the block is put in place during sleep-request
> > handling. I will see if it is possible to follow the same method as
> > gnome but it may have to be through experimentation (that'll be super
> > fun).
> >
> > The other thing I was able to find in documentation from last decade is
> > that there are two kinds of sleep, kind of as you'd expect:
> >
> > - Forced sleep where the user explicitly does something like closing a
> > laptop lid or pressing a sleep button. This kind of sleep can be
> > briefly delayed but not blocked by an application.
> >
> > - Inactive sleep where the system sleeps on user idleness. This kind of
> > sleep can be both delayed and blocked.
> >
> > Let's keep the potential semantics and processing differences in mind
> > when designing how to make this work across platforms. It may be
> > possible to have one system implementation emulate another but that
> > could be cumbersome vs. a more accommodative structure.
>
>
> Sure. Having thought a bit more I am convinced that starting the block
> before the sleep notification is the right thing, and am hopeful that
> macos can accommodate it. I think that with logind putting the block on
> AFTER the notification is actually not allowed (at least it seems that
> way in my testing.
>
> But I suspect we can accommodate both approaches if necessary.
>
> Can I get any feedback about the file descriptor closure issue? From what
> I can tell without exposing it in lisp the way I did I won't be able to
> use blocking anyway.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Fri, 07 Feb 2025 12:19:02 GMT)
Full text and
rfc822 format available.
Message #202 received at 63620 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 7 Feb 2025 19:43:32 +0800 (GMT+08:00)
> From: Andrew Cohen <acohen <at> ust.hk>
> Cc: 63620 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
> Eli Zaretskii <eliz <at> gnu.org>, michael.albinus <at> gmx.de
>
> Having thought a bit more I am convinced that starting the block
> before the sleep notification is the right thing
This sounds strange to me. Are you absolutely sure? Did you try this
on some system? Why would an application need to proactively block
sleep mode before the system announces its intention to sleep? Won't
doing that prevent sleep, including one due to system idleness,
altogether?
> I think that with logind putting the block on AFTER the notification
> is actually not allowed (at least it seems that way in my testing.
We don't need to block sleep, we only need to delay it for a short
while.
> Can I get any feedback about the file descriptor closure issue? From what
> I can tell without exposing it in lisp the way I did I won't be able to
> use blocking anyway.
Emacs has no way of manipulating handles or file descriptors. If this
is required in this case, we must expose it to Lisp in the form of
some primitive.
But since there could be only one such descriptor at any given time,
why would any Lisp program need to know its value? It sounds like we
need to record the descriptor internally, and then close it in C, no?
Maybe some D-Bus related primitive could do that?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Fri, 07 Feb 2025 12:22:01 GMT)
Full text and
rfc822 format available.
Message #205 received at 63620 <at> debbugs.gnu.org (full text, mbox):
> From: Ship Mints <shipmints <at> gmail.com>
> Date: Fri, 7 Feb 2025 07:05:58 -0500
> Cc: 63620 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
> Eli Zaretskii <eliz <at> gnu.org>, michael.albinus <at> gmx.de
>
> Do we need to consider not blocking sleep when Emacs is run in batch mode?
Why do you think batch mode should be special in this regard?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Fri, 07 Feb 2025 12:34:02 GMT)
Full text and
rfc822 format available.
Message #208 received at 63620 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Forgive me for asking something you might think is obvious. Are all the
platform initializations done even in batch? So all display/system code
works just with no initial frame?
On Fri, Feb 7, 2025 at 7:21 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Ship Mints <shipmints <at> gmail.com>
> > Date: Fri, 7 Feb 2025 07:05:58 -0500
> > Cc: 63620 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
> > Eli Zaretskii <eliz <at> gnu.org>, michael.albinus <at> gmx.de
> >
> > Do we need to consider not blocking sleep when Emacs is run in batch
> mode?
>
> Why do you think batch mode should be special in this regard?
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Fri, 07 Feb 2025 12:35:02 GMT)
Full text and
rfc822 format available.
Message #211 received at 63620 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, Feb 7, 2025 at 7:18 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > Date: Fri, 7 Feb 2025 19:43:32 +0800 (GMT+08:00)
> > From: Andrew Cohen <acohen <at> ust.hk>
> > Cc: 63620 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
> > Eli Zaretskii <eliz <at> gnu.org>, michael.albinus <at> gmx.de
> >
> > Can I get any feedback about the file descriptor closure issue? From
> what
> > I can tell without exposing it in lisp the way I did I won't be able to
> > use blocking anyway.
>
> But since there could be only one such descriptor at any given time,
> why would any Lisp program need to know its value? It sounds like we
> need to record the descriptor internally, and then close it in C, no?
> Maybe some D-Bus related primitive could do that?
>
This is why I suggested that the lower-level C code return opaque cookies
that can be used to send back to lower-level code to operate on them, such
as closing an fd.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Fri, 07 Feb 2025 12:54:02 GMT)
Full text and
rfc822 format available.
Message #214 received at 63620 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Fri, Feb 7, 2025 at 7:18 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > Date: Fri, 7 Feb 2025 19:43:32 +0800 (GMT+08:00)
> > From: Andrew Cohen <acohen <at> ust.hk>
> > Cc: 63620 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
> > Eli Zaretskii <eliz <at> gnu.org>, michael.albinus <at> gmx.de
> >
> > Having thought a bit more I am convinced that starting the block
> > before the sleep notification is the right thing
>
> This sounds strange to me. Are you absolutely sure? Did you try this
> on some system? Why would an application need to proactively block
> sleep mode before the system announces its intention to sleep? Won't
> doing that prevent sleep, including one due to system idleness,
> altogether?
>
On macOS, we can (via at least 4 different APIs with varying abilities--it
seems like a historical mess):
- Block or unblock idle sleep. When blocked, it seems we will not get an
idle sleep request from the OS since it's blocked. User-initiated sleeps
cannot be blocked.
- Receive a request to accept or veto idle sleep. macOS waits for 30
seconds for a reply and will sleep if none received.
- Receive a notification that some other application has vetoed an idle
sleep request.
- Receive a notification that the system is actually going to sleep. If
acknowledged the system will sleep immediately, assuming every other
application has also acknowledged. If not acknowledged, the system will
sleep within 30 seconds.
I will have to put together an independent test jig for this and see what
is what and discover the interactions between blocked sleep and sleep
notifications. Apple's documentation is silent on this. I will also have to
figure out which of the APIs or combinations of APIs are good ones, and not
deprecated. I have not seen deprecations in Apple's documentation--yet.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Fri, 07 Feb 2025 12:55:02 GMT)
Full text and
rfc822 format available.
Message #217 received at 63620 <at> debbugs.gnu.org (full text, mbox):
> From: Ship Mints <shipmints <at> gmail.com>
> Date: Fri, 7 Feb 2025 07:31:33 -0500
> Cc: acohen <at> ust.hk, 63620 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
> michael.albinus <at> gmx.de
>
>
> Forgive me for asking something you might think is obvious. Are all the platform initializations done even in
> batch?
No. But what part of that you think could be relevant to the issue at hand?
> So all display/system code works just with no initial frame?
Actually, there is a frame in that case, but it is not a GUI frame.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Fri, 07 Feb 2025 12:56:01 GMT)
Full text and
rfc822 format available.
Message #220 received at 63620 <at> debbugs.gnu.org (full text, mbox):
> From: Ship Mints <shipmints <at> gmail.com>
> Date: Fri, 7 Feb 2025 07:32:48 -0500
> Cc: Andrew Cohen <acohen <at> ust.hk>, 63620 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
> michael.albinus <at> gmx.de
>
> On Fri, Feb 7, 2025 at 7:18 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > Date: Fri, 7 Feb 2025 19:43:32 +0800 (GMT+08:00)
> > From: Andrew Cohen <acohen <at> ust.hk>
> > Cc: 63620 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
> > Eli Zaretskii <eliz <at> gnu.org>, michael.albinus <at> gmx.de
> >
> > Can I get any feedback about the file descriptor closure issue? From what
> > I can tell without exposing it in lisp the way I did I won't be able to
> > use blocking anyway.
>
> But since there could be only one such descriptor at any given time,
> why would any Lisp program need to know its value? It sounds like we
> need to record the descriptor internally, and then close it in C, no?
> Maybe some D-Bus related primitive could do that?
>
> This is why I suggested that the lower-level C code return opaque cookies that can be used to send back to
> lower-level code to operate on them, such as closing an fd.
I'm asking why return such cookies to Lisp at all.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Fri, 07 Feb 2025 13:04:02 GMT)
Full text and
rfc822 format available.
Message #223 received at 63620 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I see. So it would be an all-or-nothing hard-coded global, then.
On Fri, Feb 7, 2025 at 7:55 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Ship Mints <shipmints <at> gmail.com>
> > Date: Fri, 7 Feb 2025 07:32:48 -0500
> > Cc: Andrew Cohen <acohen <at> ust.hk>, 63620 <at> debbugs.gnu.org,
> monnier <at> iro.umontreal.ca,
> > michael.albinus <at> gmx.de
> >
> > On Fri, Feb 7, 2025 at 7:18 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> > > Date: Fri, 7 Feb 2025 19:43:32 +0800 (GMT+08:00)
> > > From: Andrew Cohen <acohen <at> ust.hk>
> > > Cc: 63620 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>,
> > > Eli Zaretskii <eliz <at> gnu.org>, michael.albinus <at> gmx.de
> > >
> > > Can I get any feedback about the file descriptor closure issue? From
> what
> > > I can tell without exposing it in lisp the way I did I won't be able
> to
> > > use blocking anyway.
> >
> > But since there could be only one such descriptor at any given time,
> > why would any Lisp program need to know its value? It sounds like we
> > need to record the descriptor internally, and then close it in C, no?
> > Maybe some D-Bus related primitive could do that?
> >
> > This is why I suggested that the lower-level C code return opaque
> cookies that can be used to send back to
> > lower-level code to operate on them, such as closing an fd.
>
> I'm asking why return such cookies to Lisp at all.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Fri, 07 Feb 2025 13:06:02 GMT)
Full text and
rfc822 format available.
Message #226 received at 63620 <at> debbugs.gnu.org (full text, mbox):
> From: Ship Mints <shipmints <at> gmail.com>
> Date: Fri, 7 Feb 2025 07:51:19 -0500
> Cc: Andrew Cohen <acohen <at> ust.hk>, 63620 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
> michael.albinus <at> gmx.de
>
> > Having thought a bit more I am convinced that starting the block
> > before the sleep notification is the right thing
>
> This sounds strange to me. Are you absolutely sure? Did you try this
> on some system? Why would an application need to proactively block
> sleep mode before the system announces its intention to sleep? Won't
> doing that prevent sleep, including one due to system idleness,
> altogether?
>
> On macOS, we can (via at least 4 different APIs with varying abilities--it seems like a historical mess):
>
> - Block or unblock idle sleep. When blocked, it seems we will not get an idle sleep request from the OS since
> it's blocked. User-initiated sleeps cannot be blocked.
>
> - Receive a request to accept or veto idle sleep. macOS waits for 30 seconds for a reply and will sleep if
> none received.
>
> - Receive a notification that some other application has vetoed an idle sleep request.
>
> - Receive a notification that the system is actually going to sleep. If acknowledged the system will sleep
> immediately, assuming every other application has also acknowledged. If not acknowledged, the system will
> sleep within 30 seconds.
>
> I will have to put together an independent test jig for this and see what is what and discover the interactions
> between blocked sleep and sleep notifications. Apple's documentation is silent on this. I will also have to
> figure out which of the APIs or combinations of APIs are good ones, and not deprecated. I have not seen
> deprecations in Apple's documentation--yet.
I was talking about our reaction to the system's notification that it
is about to go to sleep. The ability to block sleep regardless is a
separate feature, which doesn't need any mechanism of injecting an
event into the Emacs input queue.
For our reaction to the system's notification of an imminent sleep
mode, I'm surprised that we'd need to block sleep up front. It should
not be needed. Like macOS and MS-Windows, I believe GNU/Linux
provides the application with an ability to delay sleep, so that the
application could do what it needs in preparation for the sleep.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Fri, 07 Feb 2025 13:23:02 GMT)
Full text and
rfc822 format available.
Message #229 received at 63620 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
In nsterm.m, it says:
/* emacs -nw doesn't have an NSApp, so we're done. */
if (NSApp == nil)
That may influence if sleep/wake features are available in batch, at least
for macos, yes?
On Fri, Feb 7, 2025 at 7:54 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Ship Mints <shipmints <at> gmail.com>
> > Date: Fri, 7 Feb 2025 07:31:33 -0500
> > Cc: acohen <at> ust.hk, 63620 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
> > michael.albinus <at> gmx.de
> >
> >
> > Forgive me for asking something you might think is obvious. Are all the
> platform initializations done even in
> > batch?
>
> No. But what part of that you think could be relevant to the issue at
> hand?
>
> > So all display/system code works just with no initial frame?
>
> Actually, there is a frame in that case, but it is not a GUI frame.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Fri, 07 Feb 2025 14:35:02 GMT)
Full text and
rfc822 format available.
Message #232 received at 63620 <at> debbugs.gnu.org (full text, mbox):
>>>>> "EZ" == Eli Zaretskii <eliz <at> gnu.org> writes:
>> Date: Fri, 7 Feb 2025 19:43:32 +0800 (GMT+08:00) From: Andrew
>> Cohen <acohen <at> ust.hk> Cc: 63620 <at> debbugs.gnu.org, Stefan Monnier
>> <monnier <at> iro.umontreal.ca>, Eli Zaretskii <eliz <at> gnu.org>,
>> michael.albinus <at> gmx.de
>>
>> Having thought a bit more I am convinced that starting the block
>> before the sleep notification is the right thing
EZ> This sounds strange to me. Are you absolutely sure? Did you
EZ> try this on some system?
Yes, I am quite sure, and I have tried it extensively on my system. The
documentation is explicit, and now that I understand things better I see
why.
EZ> Why would an application need to proactively block sleep mode
EZ> before the system announces its intention to sleep?
The block does nothing until the system tries to sleep, so it makes no
difference if it is set hours before the attempt to sleep, or
milliseconds before; the only relevant thing is that the block is in
place /before/ the system starts the sleep process. Setting the block
early just /guarantees/ that the block is in place at the time sleep is
called, and otherwise has no effect. If you try to install AFTER
getting the signal, it may be too late. From the documentation (FYI
"watching" means registering a monitor for the sleep signal so that some
action can be taken when the signal is received):
"Note that watching PrepareForShutdown(true)/PrepareForSleep(true)
without taking a delay lock is racy and should not be done, as any
code that an application might want to execute on this signal might
not actually finish before the suspend/shutdown cycle is executed.
Again: if you watch PrepareForShutdown(true)/PrepareForSleep(true),
then you really should have taken a delay lock first."
EZ> Won't doing that prevent sleep, including one due to system
EZ> idleness, altogether?
No it won't. If the sleep request is initiated through logind (which on
most systems, /all/ sleep requests are) then the application that has
set the block is monitoring the PrepareForSleep signal and will do its
work and then release the block. Even if some system generates a sleep
request NOT through logind then it won't be blocked---the blocks only
apply to requests from logind. Again from the documentation
"Note that this will only be sent out for suspend/resume cycles done
via logind, i.e. generally only for high-level user-induced suspend
cycles, and not automatic, low-level kernel induced ones which might
exist on certain devices with more aggressive power management."
EZ> We don't need to block sleep, we only need to delay it for a
EZ> short while.
Sorry, I was using shorthand. When I say "block", I mean "block with
delay": if the block is not removed within 5 seconds of the sleep
request (or some other configurable time) the sleep proceeds anyway.
>> Can I get any feedback about the file descriptor closure issue?
>> From what I can tell without exposing it in lisp the way I did I
>> won't be able to use blocking anyway.
EZ> Emacs has no way of manipulating handles or file descriptors.
EZ> If this is required in this case, we must expose it to Lisp in
EZ> the form of some primitive.
Right, I suspected this. In my local version I have done exactly that:
exposed it to lisp in the form of some primitive (I just created a lisp
function `emacs-close-fd' that calls `emacs_close')
EZ> But since there could be only one such descriptor at any given
EZ> time, why would any Lisp program need to know its value? It
EZ> sounds like we need to record the descriptor internally, and
EZ> then close it in C, no? Maybe some D-Bus related primitive
EZ> could do that?
Right. The issue is that for the D-Bus case I am doing everything using
the lisp dbus API and not touching the C source. When I use the API to
install the block (by calling `dbus-call-method') all I get returned is
an integer, the file descriptor. The D-Bus API specifies that I am to
close the descriptor to release the block. But all I have in lisp is
this integer, which doesn't do me much good unless I expose the
primitive as above.
I looked through the D-Bus code and don't see any primitive that would
do this. I also asked Michael, who wasn't aware of anything either. So
as far as I can tell either we have to expose a primitive to close file
descriptors, as I have done (or something similar), or try something
more drastic in dbusbind.c that changes the way methods that return file
descriptors work (I know less than nothing about how this works, so I
can't say anything intelligent about it. But I would guess that
something major would have to be done, so that instead of the dbus
library opening the descriptor and returning it, the standard dbus
routines would have to be bypassed so that some other kind of emacs
object would be used instead).
Best,
Andy
--
Andrew Cohen
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Fri, 07 Feb 2025 14:42:01 GMT)
Full text and
rfc822 format available.
Message #235 received at 63620 <at> debbugs.gnu.org (full text, mbox):
>>>>> "EZ" == Eli Zaretskii <eliz <at> gnu.org> writes:
[...]
EZ> For our reaction to the system's notification of an imminent
EZ> sleep mode, I'm surprised that we'd need to block sleep up
EZ> front. It should not be needed. Like macOS and MS-Windows, I
EZ> believe GNU/Linux provides the application with an ability to
EZ> delay sleep, so that the application could do what it needs in
EZ> preparation for the sleep.
With logind, delaying sleep and blocking sleep are done in exactly the
same way: by calling an "Inhibit" method that returns a file
descriptor. Closing the descriptor removes the block and sleep can
proceed. The only difference is that with the delay case the sleep
proceeds after some (configurable) time even if the file descriptor is
not closed.
The documentation makes clear that the block (either for a hard block or
one with a delay) should be done at the time a monitor is installed to
watch for the sleep signal, and not wait for the signal to be generated,
which might be too late.
--
Andrew Cohen
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Fri, 07 Feb 2025 15:31:01 GMT)
Full text and
rfc822 format available.
Message #238 received at 63620 <at> debbugs.gnu.org (full text, mbox):
> From: Ship Mints <shipmints <at> gmail.com>
> Date: Fri, 7 Feb 2025 08:20:09 -0500
> Cc: acohen <at> ust.hk, 63620 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
> michael.albinus <at> gmx.de
>
> In nsterm.m, it says:
>
> /* emacs -nw doesn't have an NSApp, so we're done. */
> if (NSApp == nil)
>
> That may influence if sleep/wake features are available in batch, at least for macos, yes?
Could be. I know almost nothing about how Emacs's inner loops work on
macOS, sorry. Only that it's different from every other platform.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Fri, 07 Feb 2025 15:52:02 GMT)
Full text and
rfc822 format available.
Message #241 received at 63620 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
This works:
$ mac-emacs -Q --batch --eval '(message "%S" (boundp
'\''ns-version-string))'
t
But not the below. It looks like no accessible event loop so no sleep/wake
in batch on macOS. This could be addressed by the current NS experts. It's
not really clear why it was done this way. Running applescript
scripts doesn't have to be tied to a GUI. Neither does sleep/wake.
$ mac-emacs -Q --batch --eval '(ns-do-applescript "display notification
\"foo\"")'
+ exec /Applications/Emacs.app/Contents/MacOS/Emacs -Q --batch --eval
'(ns-do-applescript "display notification \"foo\"")'
Error: error ("Window system is not in use or not initialized")
mapbacktrace(#f(compiled-function (evald func args flags) #<bytecode
-0x1fffb8046512f81>))
debug-early-backtrace()
debug-early(error (error "Window system is not in use or not
initialized"))
ns-do-applescript("display notification \"foo\"")
command-line-1(("--eval" "(ns-do-applescript \"display notification
\\\"foo\\\"\")"))
command-line()
normal-top-level()
Window system is not in use or not initialized
On Fri, Feb 7, 2025 at 10:29 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Ship Mints <shipmints <at> gmail.com>
> > Date: Fri, 7 Feb 2025 08:20:09 -0500
> > Cc: acohen <at> ust.hk, 63620 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
> > michael.albinus <at> gmx.de
> >
> > In nsterm.m, it says:
> >
> > /* emacs -nw doesn't have an NSApp, so we're done. */
> > if (NSApp == nil)
> >
> > That may influence if sleep/wake features are available in batch, at
> least for macos, yes?
>
> Could be. I know almost nothing about how Emacs's inner loops work on
> macOS, sorry. Only that it's different from every other platform.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Fri, 07 Feb 2025 16:59:02 GMT)
Full text and
rfc822 format available.
Message #244 received at 63620 <at> debbugs.gnu.org (full text, mbox):
> From: Ship Mints <shipmints <at> gmail.com>
> Date: Fri, 7 Feb 2025 10:49:33 -0500
> Cc: acohen <at> ust.hk, 63620 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
> michael.albinus <at> gmx.de
>
> This works:
>
> $ mac-emacs -Q --batch --eval '(message "%S" (boundp '\''ns-version-string))'
> t
>
> But not the below. It looks like no accessible event loop so no sleep/wake in batch on macOS. This could be
> addressed by the current NS experts. It's not really clear why it was done this way. Running applescript
> scripts doesn't have to be tied to a GUI. Neither does sleep/wake.
Or we could decide that sleep/wake doesn't work in batch mode on NS.
Why is that a necessity?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63620; Package
emacs.
(Fri, 07 Feb 2025 17:00:02 GMT)
Full text and
rfc822 format available.
Message #247 received at 63620 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
It's not a necessity. It's for documentation completeness. Was worth
checking.
On Fri, Feb 7, 2025 at 11:58 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Ship Mints <shipmints <at> gmail.com>
> > Date: Fri, 7 Feb 2025 10:49:33 -0500
> > Cc: acohen <at> ust.hk, 63620 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
> > michael.albinus <at> gmx.de
> >
> > This works:
> >
> > $ mac-emacs -Q --batch --eval '(message "%S" (boundp
> '\''ns-version-string))'
> > t
> >
> > But not the below. It looks like no accessible event loop so no
> sleep/wake in batch on macOS. This could be
> > addressed by the current NS experts. It's not really clear why it was
> done this way. Running applescript
> > scripts doesn't have to be tied to a GUI. Neither does sleep/wake.
>
> Or we could decide that sleep/wake doesn't work in batch mode on NS.
> Why is that a necessity?
>
[Message part 2 (text/html, inline)]
This bug report was last modified 130 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.