[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [new patch] [PATCH] make org-notify support for macOS desktop notifi

From: Christian Hopps
Subject: Re: [new patch] [PATCH] make org-notify support for macOS desktop notification
Date: Tue, 6 Jul 2021 14:23:38 -0400

It supports imagemagick (specify —with-imagemagick), and it includes svg by default, I simply forked the railwaycat version and added the native notification code.


On Jul 6, 2021, at 11:30 AM, stardiviner <numbchild@gmail.com> wrote:

Thanks for your suggestion. Does your Emacs build supports imagemagick image view and svg feature support? Because company-mode now have built-in icons support. This is the reason that I switch from https://emacsformacosx.com/ to Homebrew cask Emacs version.

On Jul 6, 2021, at 12:21 PM, Christian Hopps <chopps@chopps.org> wrote:


Please consider: I added full native notification support to the popular OS X Emacs build available in homebrew. This supports rewrites notifications-notify defun to use the native code rather than dbus, and so everything "Just Works".

Info can be found here:



stardiviner <numbchild@gmail.com> writes:

Here is the new patch which invokes notifications though Emacs built-in API `ns-do-applescript`.

[2. text/x-patch; 0001-org-clock.el-Make-org-notify-support-macOS-notificat.patch]...

On Jul 6, 2021, at 8:06 AM, Tim Cross <theophilusx@gmail.com> wrote:

stardiviner <numbchild@gmail.com> writes:

On Jul 5, 2021, at 7:55 PM, Maxim Nikulin <manikulin@gmail.com> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]