[Top][All Lists]

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

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

From: stardiviner
Subject: [new patch] Re: [PATCH] make org-notify support for macOS desktop notification
Date: Tue, 6 Jul 2021 09:45:21 +0800

Here is the new patch which invokes notifications though Emacs built-in API 

Attachment: 0001-org-clock.el-Make-org-notify-support-macOS-notificat.patch
Description: Binary data

> 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

reply via email to

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