From: "Basil L. Contovounesios" <contovob@tcd.ie>
To: Michael Albinus <michael.albinus@gmx.de>
Cc: Julien Danjou <julien@danjou.info>,
Lars Ingebrigtsen <larsi@gnus.org>,
emacs-devel@gnu.org
Subject: Error handling in notifications-notify (was: Proposed changes to gnus-notifications.el)
Date: Sun, 21 Jul 2019 16:55:33 +0100 [thread overview]
Message-ID: <87h87fjsay.fsf_-_@tcd.ie> (raw)
In-Reply-To: <87wogbisby.fsf@gmx.de> (Michael Albinus's message of "Sun, 21 Jul 2019 12:40:17 +0200")
[-- Attachment #1: Type: text/plain, Size: 1450 bytes --]
Michael Albinus <michael.albinus@gmx.de> writes:
> "Basil L. Contovounesios" <contovob@tcd.ie> writes:
>
>> What is the best way to determine whether notifications are supported by
>> the current Emacs instance? I skimmed through (info "(dbus) Top") and
>> (info "(elisp) Desktop Notifications"), as well as through the syms of
>> dbusbind.c, dbus.el, and notifications.el, but did not find any clear
>> answers.
>
> (featurep 'dbusbind)
>
> checks, whether Emacs is configured to use D-Bus. This does not
> necessarily tells you that notifications are supported, but it gives you
> a strong indication for this.
Thanks, I somehow missed this check littered all over the place.
> You could also wrap the call of notifications-notify by dbus-ignore-errors.
>
> A better check would be to ping notifications-service, but this should
> be done inside notifications.el, if needed.
Indeed, these two alternatives sound like the responsibility of
notifications.el, not its users. The patch I proposed does not change
existing behaviour of gnus-notifications.el in this regard.
However, I'm not sure what the best thing to do in notifications-notify
is. So far, it has returned nil for any type of error (unless
debug-on-error is non-nil), thanks to its use of with-demoted-errors.
Would it be too backward-incompatible to change this to
dbus-ignore-errors or pinging notifications-service, as you say?
If so, how's the following docfix instead?
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0002-Document-value-of-notifications-notify-on-failure.patch --]
[-- Type: text/x-diff, Size: 3717 bytes --]
From 72e45056209f79d1a944ae7810b831cfc62f9d49 Mon Sep 17 00:00:00 2001
From: "Basil L. Contovounesios" <contovob@tcd.ie>
Date: Sun, 21 Jul 2019 15:09:54 +0100
Subject: [PATCH 2/3] Document value of notifications-notify on failure
* doc/lispref/os.texi (Desktop Notifications):
* lisp/notifications.el (notifications-notify): Document return
value of notifications-notify on failure, e.g. when D-Bus support is
not available.
---
doc/lispref/os.texi | 25 ++++++++++++++-----------
lisp/notifications.el | 11 +++++++----
2 files changed, 21 insertions(+), 15 deletions(-)
diff --git a/doc/lispref/os.texi b/doc/lispref/os.texi
index fef954eb7a..bc01f3722f 100644
--- a/doc/lispref/os.texi
+++ b/doc/lispref/os.texi
@@ -2644,22 +2644,25 @@ Desktop Notifications
Which parameters are accepted by the notification server can be
checked via @code{notifications-get-capabilities}.
-This function returns a notification id, an integer, which can be used
-to manipulate the notification item with
-@code{notifications-close-notification} or the @code{:replaces-id}
-argument of another @code{notifications-notify} call. For example:
+If successful, this function returns a notification ID, an integer,
+which can be used to manipulate the notification item with
+@code{notifications-close-notification} or as the @code{:replaces-id}
+argument of another @code{notifications-notify} call. Otherwise, if
+sending the notification failed, this function returns @code{nil}.
+This may happen when D-Bus or notification support is not available,
+for example.
+
+Here is an example demonstrating the use of action callbacks:
@example
@group
(defun my-on-action-function (id key)
(message "Message %d, key \"%s\" pressed" id key))
- @result{} my-on-action-function
@end group
@group
(defun my-on-close-function (id reason)
(message "Message %d, closed due to \"%s\"" id reason))
- @result{} my-on-close-function
@end group
@group
@@ -2667,15 +2670,15 @@ Desktop Notifications
:title "Title"
:body "This is <b>important</b>."
:actions '("Confirm" "I agree" "Refuse" "I disagree")
- :on-action 'my-on-action-function
- :on-close 'my-on-close-function)
+ :on-action #'my-on-action-function
+ :on-close #'my-on-close-function)
@result{} 22
@end group
@group
-A message window opens on the desktop. Press ``I agree''.
- @result{} Message 22, key "Confirm" pressed
- Message 22, closed due to "dismissed"
+A message window opens on the desktop. Press @samp{I agree}.
+ @print{} Message 22, key "Confirm" pressed
+ @print{} Message 22, closed due to "dismissed"
@end group
@end example
@end defun
diff --git a/lisp/notifications.el b/lisp/notifications.el
index 1d250e2d92..241f127b11 100644
--- a/lisp/notifications.el
+++ b/lisp/notifications.el
@@ -198,10 +198,13 @@ notifications-notify
Which parameters are accepted by the notification server can be
checked via `notifications-get-capabilities'.
-This function returns a notification id, an integer, which can be
-used to manipulate the notification item with
-`notifications-close-notification' or the `:replaces-id' argument
-of another `notifications-notify' call."
+If successful, this function returns a notification ID, an
+integer, which can be used to manipulate the notification item
+with `notifications-close-notification' or as the `:replaces-id'
+argument of another `notifications-notify' call. Otherwise, if
+sending the notification failed, this function returns nil. This
+may happen when D-Bus or notification support is not available,
+for example."
(with-demoted-errors
(let ((bus (or (plist-get params :bus) :session))
(title (plist-get params :title))
--
2.20.1
[-- Attachment #3: Type: text/plain, Size: 930 bytes --]
>> Currently, gnus-notifications.el checks a) directly whether
>> notifications-notify is fboundp, and b) indirectly whether
>> notifications-notify returns nil. Even without notification support,
>> (a) should always be true after loading the library, right? So the
>> question is whether (b) is a sufficient condition.
>>
>> PS Should gnus-notifications.el be extended to support
>> w32-notification-notify?
>>
>> PPS Would it be possible/welcome to provide a common interface for both
>> notifications-notify and w32-notification-notify? At the moment it
>> sounds like programmers need to choose between the two depending on
>> system-type.
>
> In ELPA, there are several notification libraries. alert.el seems to be
> the most advanced one, although it doesn't support w32-notification-notify.
Indeed, and it isn't in GNU ELPA either, though I seem to recall its
inclusion being discussed somewhere.
Thanks,
--
Basil
next prev parent reply other threads:[~2019-07-21 15:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-21 0:52 Proposed changes to gnus-notifications.el Basil L. Contovounesios
2019-07-21 8:01 ` Michael Albinus
2019-07-21 9:40 ` Basil L. Contovounesios
2019-07-21 10:40 ` Michael Albinus
2019-07-21 15:54 ` Basil L. Contovounesios
2019-07-21 17:16 ` Michael Albinus
2019-07-21 15:55 ` Basil L. Contovounesios [this message]
2019-07-21 17:21 ` Error handling in notifications-notify Michael Albinus
2019-07-21 14:34 ` Proposed changes to gnus-notifications.el Eli Zaretskii
2019-07-21 13:44 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87h87fjsay.fsf_-_@tcd.ie \
--to=contovob@tcd.ie \
--cc=emacs-devel@gnu.org \
--cc=julien@danjou.info \
--cc=larsi@gnus.org \
--cc=michael.albinus@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.