terminal-notifier callback to focus alerting buffer

[colonelpanic8]

The terminal-notifier command accepts an argument, "execute", that is an arbitrary command to execute when the user clicks on the notification popup it generates. This argument could be leveraged to activate the buffer that issued the alert command (or execute arbitrary emacs code) using the emacsclient -e command. The following has allowed me to pull up the alerting buffer by clicking a notification in my preliminary testing:

(defun alert-notifier-notify (info)
  (message "%s" info)
  (if alert-notifier-command
      (let ((args
             (list "-title"   (alert-encode-string (plist-get info :title))
                   ;;"-sender"  "org.gnu.Emacs"
                   "-message" (alert-encode-string (plist-get info :message))
                   "-execute" (switch-to-buffer-command (plist-get info :buffer)))))
        (apply #'call-process alert-notifier-command nil nil nil args))
    (alert-message-notify info)))

(defun switch-to-buffer-command (buffer-name)
  (emacsclient-command (format "(switch-to-buffer \\\"%s\\\")" buffer-name)))

(defun emacsclient-command (command)
  (format "\"emacsclient --server-file='%s' -e '%s'\"" server-name command))

The main problems with this approach are the brittleness of relying on server-name, and the fact that sender has to be removed for some odd reason.

Would it be worth it to include something like this in the main repository? Perhaps it could be an optional piece of functionality that would have to be explicitly enabled?

[colonelpanic8]

You would probably want to add a osascript -e 'tell application "Emacs" to activate' to the emacs client command to make the focus go to emacs. The problem with this is that that command wont work for people using terminal or X11 emacs.

[colonelpanic8]

@jwiegley Any thoughts about this? If you don't think it would be appropriate to add this to alert.el, I totally understand.

[jwiegley]

I think this falls into the realm of "better offered as a separate add-on package". I'd be happy to link to it from a "contrib" section in the README.

[colonelpanic8]

Yeah, that probably makes the most sense. My only concern on that front --and the whole reason I brought this up here instead of doing that to begin with-- is that doing so either requires the definition of a new notification type or a patch to alert-notifier-notify. What if the only thing added to alert was a function variable that is evaluated in alert-notifier-notify to determine the value passed to the '-execute' flag (when defined). The default behavior would still be to not pass the -execute flag, as a value would be passed only when the function variable is non-nil.

If you don't think that this modification is a good idea, do you think it would be better to define a completely new notification type or to redefine alert-notifier-notify?

[jwiegley]

I certainly want alert.el to be easy for others to write extension packages for it, so if you need that sort of change to get your module written, I'd happily accept it.