Hi Chris, thanks for your work. I have a question, will your patch of notification code be merged to upstream? If yes, I think my patch will be not necessary. If no, then I think add a my workaround for macOS is considerable. > On Jul 7, 2021, at 2:23 AM, Christian Hopps wrote: > > It supports imagemagick (specify —with-imagemagick), and it includes svg by default, I simply forked the railwaycat version and added the native notification code. > > Thanks, > Chris. > >> On Jul 6, 2021, at 11:30 AM, stardiviner > 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 > wrote: >>> >>> Hi, >>> >>> 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: >>> >>> https://github.com/choppsv1/homebrew-emacsmacport >>> >>> Thanks, >>> Chris. >>> >>> stardiviner > 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 > wrote: >>>>> >>>>> >>>>> stardiviner > writes: >>>>> >>>>>>> On Jul 5, 2021, at 7:55 PM, Maxim Nikulin > 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 >>>>>>> implemented. >>>>>>> >>>>>>> >>>>>> 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 >>>>> >>> >> >