Add org-notify option to org-layer #14396

dalanicolai · 2021-02-19T23:19:12Z

This PR adds notifications via org-notify as an option to the org layer. Org-notify uses the Emacs notifications package, which works great with desktop notification systems that communicate via the dbus. Also, it should work well on Windows. I don't know about Mac, but it would be very easy to add some org-notify-action-alert function to the org-notify package (a simple copy of the org-notify-action-message with `message replaced by alert).

lebensterben · 2021-02-19T23:53:15Z

org-notify was last updated in 2012. There's a risk of incompatibility with future Emacs version.

A more recent package is org-alert https://github.com/spegoraro/org-alert, which was last updated 3 years ago.

smile13241324

Looks promising. I still found some smaller issues and questions you should check before this can be merged.

@lebensterben can you give a short overview about the difference between org-notify and org-alarm? To be honest I would prefer the one being better maintained to be honest.

layers/+emacs/org/README.org

smile13241324 · 2021-02-20T06:56:02Z

layers/+emacs/org/packages.el

@@ -588,6 +590,19 @@ Headline^^            Visit entry^^               Filter^^                    Da
      (kbd "M-SPC") 'spacemacs/org-agenda-transient-state/body
      (kbd "s-M-SPC") 'spacemacs/org-agenda-transient-state/body)))

+(defun org/init-org-notify ()
+  (use-package org-notify
+    :config


Can we lazy load the package?

Ah yes, we could lazy load it. I first loaded it :after org-agenda, but then I figured that users would like the notification daemon to start at Spacemacs startup. But the org-notify-start function is autoloadable so yes, we could lazy load it (althoguh it would still start at startup if users choose to start the daemon at startup).

Are you sure, the config code is only executed when the package is loaded, so if you call org-notifiy-start in there and lazyload the autoloading on that function will not trigger it. Instead you would need to load the server in the init part, if requested.

Yes it should be moved too :init then also 👍

Ah okay, it looks like org-notify-start is not autoloadable (I just mistakingly remembered to have seen it). So I think we should keep it as it is now. Do you think I should create a PR for making it autoloadable?

I think you can declare it autoloadable in use-package directly using the :commands tag. Still an up-stream PR would be nice for the rest of the emacs world.

Ah great! I did not know that feature yet

layers/+emacs/org/packages.el

dalanicolai · 2021-02-20T07:22:34Z

@lebensterben Thanks for checking the PR. Actually I see that I have not been clear in the PR message, but I meant that we could easily make org-notify support (extend it with) alert notifications. But that would be only required for Macs because on Linux and Windows, the Emacs notification package provides a better notification system. Really, I have tested both the alert package and the notifications package, and the notifications package really is more powerful because it actually communicates via the dbus, while org-alert only sends out messages. (Just quickly try and see how well the proposed feature in this PR works, at least when using linux. The dbus communication is great!).

So I am quite confident that org-notify is the best option. There is quite some confusion about notifications in the community (which for me personally was mainly caused by the existence of the alert package.

So let me start with the main culprit. org-alert is indeed a package by John Wiegley, which of course makes users (including myself) think it is probably an enhanced version of what was available. But after looking into it, I have found that the notification packages is a better (and more modern) package for providing desktop notifications. I have looked closely into it (I have even created two PR's for org-alert, of which the second one is an update of its documentation to include a reference to Emacs its notification package

It took me actually a long research to finally get to this, what should be, most straightforward solution of using org-notify. I have checked out, and inspected many packages:

org-alert
and its updated/enhanced forks
org-wild-notifier (which already looks better than org-alert)
appt.el

But all these packages have flaws. Org-alert and org-wild-notifier use org-alert, which might appear to be better but as I explained above, it is not. Additionally they use complicated ways to retrieve the correct headlines (e.g. scheduled and deadlines).
org-notify uses a much cleaner way to obtain the correct headlines, and I would say its code, despite being older, is more modern and more stable than that of org-alert and org-wild-notifier (some of the org-alert forks already improve the way it retrieves headlines, but still org-notify does it cleaner).

Also [org-alert] has a very limited notification system of only checking and showing notifications periodically (see here.

org-wild-notifier describes org-notify to be complicated, but I would not call it very complicated, and for sure the code of org-notify is much cleaner than that of org-wild-notifier. org-wild-notifier uses a very cumbersome process to retrieve correct headlines, while org-notify uses a very clean way for retrieving them (using the org-elements API)

the appt.el package, I have checked out also, because the first two packages did not satisfy. But indeed this package I would say uses old and deprecated ways.

So finally about the incompatability risk, it seems that org-notify actually has the lowest risk of becoming incompatible. It might be true that org-alert works better for Macs but it is 1 second work to add an alert function to org notify (as I said in the PR message, just use a copy of the org-notify-action-message function.

dalanicolai · 2021-02-20T07:37:32Z

Let me elaborate a little more.

org-alert and org-wild-notifier both let users configure the type of headlines they would like to include (default is DEADLINES and SCHEDULED). So this would probably be nice for org-notify too.
Also org-wild-notifier uses a nice way to schedule the notifications, which could be nice to have in org-notify too, although I think it is not really worth the trouble.

But regarding the (in)compatability, I think org-notify is the way to go, it is clean code and should be used as a starting point. Of course users are welcome to enhance/extend its features, but I think we should guide them to the right package (at least in my opinion:) to start with. They could use the org-alert and org-wild-notifier packages for inspiration.

smile13241324 · 2021-02-20T07:58:22Z

Thanks for the very detailed explanation @dalanicolai. I agree with you lets start with this package, if features are missing we could still do PRs on upstream. Maybe we can contribute to solving this entire emacs notification confusion by focusing on the package with the cleanest code and extend it where necessary.

lebensterben · 2021-02-20T17:42:29Z

@dalanicolai
Thanks for your detailed explanation.

One minor issue, the link in you commit is not the original org-notify.
From org-mode's webpage, the raw file is available here

lebensterben · 2021-02-20T17:44:28Z

This seems to be actively maintained.

https://code.orgmode.org/bzg/org-mode/src/master/contrib/lisp/org-notify.el

wztdream · 2021-02-22T05:10:49Z

Only to notice that emacs function notifications-notify seems not compatible with gnome3.36 (ubuntu20.04 gnome-shell)
You can check it by:

using ubuntu20.04 os
modify below code, change to your sound file path, then eval it, then there should be no desktop notify.

(notifications-notify
      :title "some title"
      :sound-file file-of-sound-file
      )

remove the :sound-file item, then restart gnome-shell, then re-eval it, it should work correctly
So it seems notifications-notify have trouble if it need play sound files in gnome-shell 3.36

lebensterben · 2021-02-22T11:15:07Z

@wztdream

In order to use this functionality on POSIX hosts, Emacs must have been compiled with D-Bus support, and the notifications library must be loaded.

https://www.gnu.org/software/emacs/manual/html_node/elisp/Desktop-Notifications.html

dalanicolai · 2021-02-22T14:50:46Z

I have checked here on Ubuntu 20.10 with gnome 3.38.3 and also on Fedora 33 with KDE plasma 5.20.5. On both systems notifications seem to work fine, except that the sound does not play even if the :sound-file keyword is included.

On Ubuntu I tried with Emacs from the default Ubuntu repo, and it worked alright (except for playing the sound, but the notifications were still working even when the :sound-file keyword was included). Anyway, seems like it has been build with D-Bus support.
The notifications library should gets loaded from org-notify-action-notify (so it is not loaded before that is called for the first time)

wztdream · 2021-02-23T05:23:09Z

@ lebensterben I install emacs27 with this ppa

it was compiled with dbus
eval (notifications-get-capabilities) shows (:actions :body :body-markup :icon-static :persistence :sound) and it also support play sound.
I (require 'notifications) ahead but there is no difference, desktop notify seems hang, I mean no pop up window for all notifications, not only emacs but all notifications from os not showing up, no sound played too
if remove the :sound-file item, restart gnome-shell, then every thing works fine
I checked on ubuntu18.04 with lower version of gnome-shell, with emacs from same PPA, it works fine
So it seems this is gnome-shell bug

lebensterben · 2021-02-23T05:39:28Z

I don't use gnome now so I cannot reproduce this.

wztdream · 2021-02-23T06:32:38Z

I just report this bug to gnome-shell, hope this will be solved there issue

dalanicolai · 2021-02-23T08:54:47Z

@wztdream Well I noticed that in Gnome 3.38 the notifications do get added to the notifications list (in the clock dropdown menu), therefore I said they were working alright. But actually I agree with you that it does not work alright, because it should indeed show pop-ups and play sounds also. So it is great that you created the gnome-shell bug report!
(in KDE plasma the pop-ups work fine, but the sound does not work. I am forced to work with KDE at the moment. It is very fine but it isn't gnome:)).

dalanicolai · 2021-02-23T22:55:31Z

Okay guys, after using org-notify for the last few days, I noticed that I really prefer the notification 'configuration style' of org-wild-notifier. So I continued to look for better alternatives (maybe creating one), including again org-wild-notifier, and now I changed my mind about that package for a few reasons:

I got some wrong ideas about the alert package. At first, I preferred to use the notifications package, because it comes with Emacs, and the development of org-alert seems slow. Besides that, there is still the bug that notifications using the libnotify option don't work. On the other hand, org-notify uses the potentially nice feature of the notifications package that notifications can be suspended from the desktop notification pop-up. But now I found that, the alert package actually provides an option to use the notifications package (although suspending the notifications does not seem very useful anyway). Also, I noticed that it is actually available from Melpa (did not notice that before).
The way org-wild-notifier retrieves entries looked less elegant/efficient to me because it does not use the org-elements-api but instead first lets the agenda format its entries, and then retrieves them from there. But now I think that is probably an easy way to do it, and moreover it is done asynchronously. (Also I did/do not like dash package function names that org-wild-notifier uses everywhere, because they are not very informative. But 'unfortunately' those functions seem very powerful/elegant. Finally the package gave an error here at first, which is gone now after some updates.)
I already mentioned in an earlier comment that I prefer the configuration and scheduling style of org-wild-notifier. Just see how it can be configured yourself (org-notify only allows notifications of TODO headlines that include a DEADLINE stamp).

So now, I am wondering... should we just replace the org-notify package, or should we make both packages available?

lebensterben · 2021-02-24T08:37:24Z

using dash is plus for me.
CL simulation is too verbose.
Symbols in dash resembles the feeling of some Haskell operators.

But not using org-elemnt API is quite disappointing. Why giving up the benefit of dealing with AST....