2011-12-22

sauron: keeping an eye on what's going on

I'm a fairly busy person, and need to keep track of a lot of things. That includes following a bunch of internal IRC channels, attending meetings, meeting deadlines and so on. But I don't want to stare at my org-mode calendar, or flip through ERC buffers all the time.

Instead, I'd like to have one little emacs frame (window) that gathers these ('events'), and transfers me to wherever the event came from when I click it - some IRC-channel in ERC, my org-calendar etc. and other inputs. Note, using Bitlbee, you can include Facebook-contacts, GoogleTalk-buddies and Twitter-tweets, … in ERC - so, you can track just about anything.

In addition, with so many inputs, I'd also like the possibility to filter out unwanted events, and generate various light/sound effects and fireworks, proportional to the priority of the event.

For all this, I wrote a little emacs-tool called Sauron that does just that. M-x sauron-start pops up a frame that receives events, and M-x sauron-stop hides it and stops listening. It works with ERC, org, and listens for D-Bus messages; so it's pretty easy to get events from all over the place.

It's a bit of a balancing act to get all the important information while not being swamped in noise, but Sauron allows you to fine-tune it to whatever works the best for you. I've tried to have sane defaults though, so things should mostly work without too much configuration - but if you need the power, it's there. I also added some convenience functions to make it easy to get sounds and other special effects.

So - it's brand new, it is of seems-to-work-for-me-quality, and I'd like to invite others to try it out, hack it, give feedback, add new back-ends and so on – what better Christmas present to ask for!

There's documentation, examples etc. to be found in Sauron's github repository.

16 comments:

qdot said...

Oh man. I've been getting sick of todochiku (or as of emacs24, notifications.el) + notify-send losing information when I'm not around to see the event, popping dialogs that only show one at a time, etc... Was just thinking I'd like a single window that keeps this stuff around that I could pop whenever I needed. I'll probably just throw it in a workgroups.el workgroup to bring up whenever I want. This'll be awesome, thanks!

Anonymous said...

The functionality of sauron has a *lot* in common with alert.el that I wrote, for managing alerts coming from anywhere inside of Emacs. Maybe there's room here for merging some functionality?

https://github.com/jwiegley/alert

John

Anonymous said...

Well that sounds like exactly what I've been wanting for the past couple of months. Cheers. (And ditto to John.)

Anonymous said...

p.s. Love the name :)

djcb said...

@qdot: hope you'll like it -- it's highly tuned to my particular needs so far, I'd be happy to hear suggestions if it does work for you.

@Anonymous: 'alert' looks like a nice, generic/programmable way to show events - and I wish I could write nice elisp like that some day! It seems the most straightforward way to combine with sauron would be to add some 'sauron-fx-alert' (analogous to the other 'sauron-fx-...' functions) and map the priorities to the alert types. I'll see if I can write something for that.

Anonymous said...

Hey that's a really nice tool !
Thanks !

Anonymous said...

Thank you for Sauron; it's working very nicely, and already greatly appreciated.

Jianing YANG said...

Awesome! What a handy tool. It works fine on my Macbook. Thanks.

Anonymous said...

Can I configure Sauron to notify me when a new message arrives on my Gmail account?

djcb said...

@Anonymous: you can get GMail
notifications by writing a little cron script that combines [1] and sauron-msg (dbus)

[1] http://www.commandlinefu.com/commands/view/3380/check-your-unread-gmail-from-the-command-line

ramestica said...

many thanks for this tool!

1. it will be nice if you could change sauron's frame creation to make-frame and pass there frame parameters. otherwise my windows manager does not apply window rules as expected.

2. what's the proper way for shutting down? I added sauron-stop to kill-emacs-hook but the frame remains there.

many thanks again,
Rodrigo

djcb said...

@ramestica: any idea what the make-frame should look like? I guess that's also the reason for your second prob.

Note, the current sauron also supports the sauron window the be part of the existing frame.

ramestica said...

a modified version of sr-show-in-separate-frame is shown below. The 'name' parameter is useful for me to associate a window rule.

For shutting down I'm using now delete-frame-functions, to which I added one method that detects the frame from where sauron was started by means of a custom parameter (set-frame-parameter). In this function sauron-stop is invoked. All this being very idiosyncratic to the way I use org mode (normally i open every org mode file in only one single frame.)

(defun sr-show-in-separate-frame ()
"Show the sauron buffer in a separate frame."
(setq sr-buffer (sr-create-buffer-maybe))
(let* ((win (get-buffer-window sr-buffer))
(frame (and win (window-frame frame))))
(if (and frame win)
((progn )
(select-window win)
(make-frame-visible frame))
(setq sr-frame (make-frame (append
`((name . "SauronFrame") (menu-bar-lines . 0))
(x-parse-geometry sauron-frame-geometry))))
(set-window-buffer (frame-selected-window sr-frame) sr-buffer))))

Samuel Wales said...

I like your blog, your color theme, the name "sauron", the package idea, and the idea of integrating similar packages somehow.

I think I like the name "sauron" the most. :)

ramestica said...

Hello djcb,

the lisp code in my previous posting is wrong, even though it seems to work there are mistakes in the syntax. I have cloned now from github and I have a now a proper diff to the change I really meant, it is attached below. Perhaps you could simply edit the previos comment replacing the code by the diff.

There is one thing in the original code that I cannot understand. The second form in 'let*', 'frame' seems to be a variable to set, but it is also passed as parameter to window-frame. How is this?

Rodrigo

diff --git a/sauron.el b/sauron.el
index e7e84c9..b7c6e09 100644
--- a/sauron.el
+++ b/sauron.el
@@ -455,23 +455,24 @@ current frame."
(let* ((win (get-buffer-window sr-buffer))
(frame (and win (window-frame frame))))
(if (and frame win)
(progn
(select-window win)
(make-frame-visible frame))
(progn
- (switch-to-buffer-other-frame sr-buffer)
(let ((frame-params
(append
- `((tool-bar-lines . 0) (menu-bar-lines . 0)
- (unsplittable . t) (sticky . ,sauron-sticky-frame))
+ `((name . "SauronFrame")
+ (tool-bar-lines . 0) (menu-bar-lines . 0)
+ (unsplittable . t) (sticky . ,sauron-sticky-frame))
(x-parse-geometry sauron-frame-geometry))))
- (modify-frame-parameters nil frame-params))))
- (if sauron-hide-mode-line
- (setq mode-line-format nil))
+ (setq sr-frame (make-frame frame-params))
+ (set-window-buffer (frame-selected-window sr-frame) sr-buffer))))
+ (if sauron-hide-mode-line
+ (setq mode-line-format nil))
(set-window-dedicated-p (selected-window) t)))

(defun sr-split-window-below (new-win-size)
"Split the window, return the new window below. We need this
function because emacs 23 does not support the negative size
argument to split-window."
(split-window

Mash said...

I have just started using Stumpwm, and wondering how I could get Sauron to output lines to stumpwm's mode-line?

I can't imagine it would be too difficult. Any ideas how I could do this?