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/ <https://emacsformacosx.com/> to Homebrew cask Emacs version.
> On Jul 6, 2021, at 12:21 PM, Christian Hopps <cho...@chopps.org> 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 <numbch...@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 <theophil...@gmail.com> wrote: >>> >>> >>> stardiviner <numbch...@gmail.com> writes: >>> >>>>> On Jul 5, 2021, at 7:55 PM, Maxim Nikulin <maniku...@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 >>>>> 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 >>> >
