From: stardiviner <firstname.lastname@example.org>
To: Tim Cross <email@example.com>
Cc: Org-mode <firstname.lastname@example.org>
Subject: [new patch] Re: [PATCH] make org-notify support for macOS desktop notification
Date: Tue, 6 Jul 2021 09:45:21 +0800 [thread overview]
Message-ID: <7318E1D0-613A-4301-8097-779D3FEF1105@gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 100 bytes --]
Here is the new patch which invokes notifications though Emacs built-in API `ns-do-applescript`.
[-- Attachment #2: 0001-org-clock.el-Make-org-notify-support-macOS-notificat.patch --]
[-- Type: application/octet-stream, Size: 1047 bytes --]
From 9dcf98905cd2d11c899f8a13238601345a6361cc Mon Sep 17 00:00:00 2001
From: stardiviner <email@example.com>
Date: Sun, 4 Jul 2021 08:13:43 +0800
Subject: [PATCH] org-clock.el: Make org-notify support macOS notification
* lisp/org-clock.el (org-show-notification): Add support for macOS
lisp/org-clock.el | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index cd930e875..efc3a2f3b 100644
@@ -859,6 +859,10 @@ use libnotify if available, or fall back on a message."
(lambda () (w32-notification-close id)))))
+ ((fboundp 'ns-do-applescript)
+ (format "display notification \"%s\" with title \"Org mode notification\""
+ (replace-regexp-in-string "\"" "#" notification))))
:title "Org mode message"
2.30.1 (Apple Git-130)
[-- Attachment #3: Type: text/plain, Size: 2948 bytes --]
> On Jul 6, 2021, at 8:06 AM, Tim Cross <firstname.lastname@example.org> wrote:
> stardiviner <email@example.com> writes:
>>> On Jul 5, 2021, at 7:55 PM, Maxim Nikulin <firstname.lastname@example.org> wrote:
>>> On 05/07/2021 10:50, stardiviner wrote:
>>>> I updated the patch, I found the package `osx-lib` contains solution.
>>>> So I removed the directly osascript process invocation.
>>> I have no objections any more. On the other hand I have no access to macOS, so
>>> I have not tested this patch. Feel free to ignore comments from this message,
>>> they are mostly matter of taste.
>>> I expect that a simple script "notify-send" may allow to avoid modification of
>>> code. Something like (untested, unsure concerning "quoted form of ...")
>>> #!/usr/bin/env osascript
>>> display notification (item 1 of argv)
>>> However if osx-lib in is installed automatically, it may be more convenient.
>>> Unsure if some of currently supported linux distributions have notify-send
>>> that can not handle title as the first argument.
>>>> - ((fboundp 'notifications-notify)
>>>> + ((and (eq system-type 'gnu/linux) (fboundp 'notifications-notify))
>>> Does it mean that `notifications-notify' is bound but it does not work on
>>> macOS? If so, maybe it is better to put new clause for 'darwin above and to
>>> drop 'gnu/linux here. From my point of view, it is preferable to avoid
>>> additional requirement for `notifications-notify'. If someone will create a
>>> feature request for `notifications-notify' for macOS, it will just work
>>> without installing of additional packages as soon as such feature is
>> I indeed tried `notifications-notify`. And it does not work, reports error that
>> it needs dbus. PS. I used the Homebrew formulae version Emacs.
>> I considered the order of conditions. Because notifications and notify-send etc
>> requires dbus. So I guess only Linux supports that. So add system-type detection
>> will be better. WDYT?
> I think you can add dbus support to macOS using homebrew and that might
> resolve the issue. At the very least, this will need to be investigated
> because otherwise, adding this patch may break configurations for users
> who have added dbus support via homebrew and have notifications working,
> but have not installed the osx-lib package.
> My only small concern with your proposed changes is that it will add a
> dependency on a new package osx-lib, which I think is only available in
> melpa. At the very least, this will need to be documented somewhere.
> However, I'm not sure what the situation is wrt adding code which
> depends on an external package which is not available in either elpa or
> nongnuELPA? As org mode is a part of GNU Emacs, I suspect that any code
> which 'encourages' the use of melpa packages will not be acceptable.
> Tim Cross
next prev parent reply other threads:[~2021-07-06 1:45 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-04 0:23 [PATCH] make org-notify support for macOS desktop notification stardiviner
2021-07-04 5:48 ` Maxim Nikulin
2021-07-05 3:50 ` stardiviner
2021-07-05 11:55 ` Maxim Nikulin
2021-07-05 22:36 ` stardiviner
2021-07-06 0:06 ` Tim Cross
2021-07-06 1:37 ` stardiviner
2021-07-06 8:12 ` Tim Cross
2021-07-06 1:45 ` stardiviner [this message]
2021-07-06 4:21 ` [new patch] " Christian Hopps
2021-07-06 15:30 ` [new patch] " stardiviner
2021-07-06 18:23 ` Christian Hopps
2021-07-08 0:00 ` stardiviner
2021-07-08 8:59 ` Christian Hopps
2021-07-08 9:35 ` STOP this patch for now stardiviner
2021-07-08 12:02 ` Christian Hopps
2021-07-06 12:13 ` [PATCH] make org-notify support for macOS desktop notification Maxim Nikulin
2021-09-26 8:52 ` [new patch] " Bastien
2021-09-30 15:01 ` Max Nikulin
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:
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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 public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).