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 <chopps@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 <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
>>>>> 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
>>> 
>