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