Gnus and new mail notification

Gnus and new mail notification

[Yuri D'Elia]

I wasn't happy with the existing new mail notification scripts that I've
found on emacswiki.

I've put together a new script, called "gnus-notify"[1], that can call
any arbitrary program when new messages are received. The default uses
the 'notify-send' program (part of libnotify's library) which creates
little popup messages. This is especially useful if you have virtual
desktops and leave Gnus running with gnus-demon.

The result (showing Gnus + awesomewm + libnotify-bin on Debian) is shown
here:

  http://www.thregr.org/~wavexx/hacks/gnus-notify.png

You can also do arbitrary stuff by either setting a different
executable, or supplying an entirely new notification function.
Simply read the commentary in the source.

gnus-notify.el is available at:

  http://www.thregr.org/~wavexx/hacks/gnus-notify.el

Merry christmas :)

[1] I know there's already a gnus-notify.el script, but I wasn't able to
    come up with a better name.

Re: Gnus and new mail notification

[Philipp Haselwarter]

[-- Attachment #1: Type: text/plain, Size: 908 bytes --]

looks useful!

On Sat, 25 Dec 2010 00:33:12 +0100, Yuri D'Elia <wavexx@users.sf.net> said:

---8<---[snipped 23 lines]---8<---

YD> [1] I know there's already a gnus-notify.el script, but I wasn't
YD> able to come up with a better name.

Please try harder, there are already at least two with that name:

http://www.mail-archive.com/gnu-emacs-sources@gnu.org/msg01615.html
http://www.emacswiki.org/emacs/gnus-notify.el

and you do something different (*desktop notification* instead of *mode
line* stuff)!


While I was testing you lib, I discovered that
`gnus-newsrc-alist'-elements `g' can contain 3 different type elements
at (nth 2 g) (ie `gnus-info-read'):
- `nil'
- a list, like '(1 . 140)
- a list of lists, like '((1 . 9))

Obviously, a cdar on a list (eg. (cdar '(1 . 140))) is invalid, which
can result in problems in `gnus-notify-check'.

So here's a patch to work around that data inconsistency:

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch to make `gnus-notify-check' more robust --]
[-- Type: text/x-patch, Size: 549 bytes --]

--- a/gnus-notify.el	2010-12-25 04:28:54.600753814 +0100
+++ b/gnus-notify.el	2010-12-25 04:29:07.473993965 +0100
@@ -110,7 +110,10 @@
   (interactive)
   (let ( (updated-groups '()) )
     (dolist (g gnus-newsrc-alist)
-      (let ( (read (cdar (gnus-info-read g))) )
+      (let ( (read (or
+                    (and (listp (car (gnus-info-read g)))
+                         (cdar (gnus-info-read g)))
+                    (cdr (gnus-info-read g)))) )
 	(when read
 	  (let* ( (name (gnus-info-group g))
 		  (unread (gnus-group-unread (car g)))

[-- Attachment #3: Type: text/plain, Size: 662 bytes --]


Furthermore, I saw that you directly added hooks at the end; referring
to the "Emacs Lisp Coding Conventions" at

http://www.gnu.org/software/emacs/elisp/html_node/Coding-Conventions.html
,----
| Simply loading a package should not change Emacs's editing
| behavior. Include a command or commands to enable and disable the
| feature, or to invoke it.
| 
| This convention is mandatory for any file that includes custom
| definitions. If fixing such a file to follow this convention requires an
| incompatible change, go ahead and make the incompatible change; don't
| postpone it. 
`----


You can simply wrap a function around the adding/removal of the hooks:

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: Add functions to turn notification on/off --]
[-- Type: text/x-patch, Size: 732 bytes --]

--- b/gnus-notify.el	2010-12-25 04:29:07.473993965 +0100
+++ c/gnus-notify.el	2010-12-25 05:13:46.467275657 +0100
@@ -135,7 +135,17 @@
 
 
 ;; Hooks into gnus
-(add-hook 'gnus-after-getting-new-news-hook 'gnus-notify-check)
-(add-hook 'gnus-started-hook 'gnus-notify-check)
+;;;###autoload
+(defun gnus-notify-on ()
+  "Add hooks for `gnus-notify-check'"
+  (interactive)
+  (add-hook 'gnus-after-getting-new-news-hook 'gnus-notify-check)
+  (add-hook 'gnus-started-hook 'gnus-notify-check))
+
+(defun gnus-notify-off ()
+  "Remove hooks for `gnus-notify-check'"
+  (interactive)
+  (remove-hook 'gnus-after-getting-new-news-hook 'gnus-notify-check)
+  (remove-hook 'gnus-started-hook 'gnus-notify-check))
 
 (provide 'gnus-notify)

[-- Attachment #5: Type: text/plain, Size: 153 bytes --]



And I noticed that you put spaces around the enclosing parentheses of
your let-assignments, which I found a bit weird, so here's a whitespace
patch :p

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #6: fix `let's --]
[-- Type: text/x-patch, Size: 1048 bytes --]

--- c/gnus-notify.el	2010-12-25 04:29:14.390610600 +0100
+++ d/gnus-notify.el	2010-12-25 04:35:41.004238410 +0100
@@ -108,18 +108,18 @@
 
 (defun gnus-notify-check (&rest ignored)
   (interactive)
-  (let ( (updated-groups '()) )
+  (let ((updated-groups '()))
     (dolist (g gnus-newsrc-alist)
-      (let ( (read (or
+      (let ((read (or
                     (and (listp (car (gnus-info-read g)))
                          (cdar (gnus-info-read g)))
-                    (cdr (gnus-info-read g)))) )
+                    (cdr (gnus-info-read g)))))
 	(when read
-	  (let* ( (name (gnus-info-group g))
+	  (let* ((name (gnus-info-group g))
 		  (unread (gnus-group-unread (car g)))
 		  (count (+ read unread))
 		  (old-count (cdr (assoc name gnus-notify-counts)))
-		  (notify (gnus-group-find-parameter name 'group-notify)) )
+		  (notify (gnus-group-find-parameter name 'group-notify)))
 	    (when (or
 		    (and (eq gnus-notify-mode 'gnus-notify-all-except) (not notify))
 		    (and (eq gnus-notify-mode 'gnus-notify-explicit) notify))

[-- Attachment #7: Type: text/plain, Size: 107 bytes --]

(don't take this one too seriously ;)


How about making it a global minor mode?


-- 
Philipp Haselwarter

[-- Attachment #8: Type: text/plain, Size: 161 bytes --]

_______________________________________________
info-gnus-english mailing list
info-gnus-english@gnu.org
http://lists.gnu.org/mailman/listinfo/info-gnus-english

Re: Gnus and new mail notification

[Yuri D'Elia]

On Sat, 25 Dec 2010 14:10:11 +0100, Philipp Haselwarter wrote:
> Please try harder, there are already at least two with that name:
>
> http://www.mail-archive.com/gnu-emacs-sources@gnu.org/msg01615.html
> http://www.emacswiki.org/emacs/gnus-notify.el
>
> and you do something different (*desktop notification* instead of *mode
> line* stuff)!

gnus-desktop-notify? gnus-ext-notify?

> While I was testing you lib, I discovered that
> `gnus-newsrc-alist'-elements `g' can contain 3 different type elements
> at (nth 2 g) (ie `gnus-info-read'):
> - `nil'
> - a list, like '(1 . 140)
> - a list of lists, like '((1 . 9))
>
> Obviously, a cdar on a list (eg. (cdar '(1 . 140))) is invalid, which
> can result in problems in `gnus-notify-check'.

I noticed that, though by reading the source I don't understand how the
list of list is actually used.

It's also weird how the unread count is stored (in a text-property
instead of using newsrc-alist), requiring you to perform an additional
lookup using gnus-group-unread.

> http://www.gnu.org/software/emacs/elisp/html_node/Coding-Conventions.html
> ,----
> | Simply loading a package should not change Emacs's editing
> | behavior. Include a command or commands to enable and disable the
> | feature, or to invoke it.
> | 
> | This convention is mandatory for any file that includes custom
> | definitions. If fixing such a file to follow this convention requires an
> | incompatible change, go ahead and make the incompatible change; don't
> | postpone it. 
> `----
>
> You can simply wrap a function around the adding/removal of the hooks:
<...>
> How about making it a global minor mode?

Any pointer in how to do that?
I don't do elisp very often.

> And I noticed that you put spaces around the enclosing parentheses of
> your let-assignments, which I found a bit weird, so here's a whitespace
> patch :p

I like the fact that assignments line-up this way:

(let ( (...)
       (...) )
     ...)

I don't remember where I first saw this style.

> (don't take this one too seriously ;)

Shouldn't I? ;)

Re: Gnus and new mail notification

[Tassilo Horn]

Yuri D'Elia <wavexx@users.sf.net> writes:

Hi Yuri,

>> and you do something different (*desktop notification* instead of
>> *mode line* stuff)!
>
> gnus-desktop-notify? gnus-ext-notify?

I like the former, cause desktop notifications is the common term for
that kind of notifications.

>> How about making it a global minor mode?
>
> Any pointer in how to do that?
> I don't do elisp very often.

,----[ C-h f define-global-minor-mode RET ]
| define-global-minor-mode is an alias for `define-globalized-minor-mode' in
| `easy-mmode.el'.
| 
| (define-global-minor-mode GLOBAL-MODE MODE TURN-ON &rest KEYS)
| 
| Make a global mode GLOBAL-MODE corresponding to buffer-local minor MODE.
| TURN-ON is a function that will be called with no args in every buffer
|   and that should try to turn MODE on if applicable for that buffer.
| KEYS is a list of CL-style keyword arguments.  As the minor mode
|   defined by this function is always global, any :global keyword is
|   ignored.  Other keywords have the same meaning as in `define-minor-mode',
|   which see.  In particular, :group specifies the custom group.
|   The most useful keywords are those that are passed on to the
|   `defcustom'.  It normally makes no sense to pass the :lighter
|   or :keymap keywords to `define-globalized-minor-mode', since these
|   are usually passed to the buffer-local version of the minor mode.
| 
| If MODE's set-up depends on the major mode in effect when it was
| enabled, then disabling and reenabling MODE should make MODE work
| correctly with the current major mode.  This is important to
| prevent problems with derived modes, that is, major modes that
| call another major mode in their body.
`----

There's also an example in

,----[ (info "(elisp)Defining Minor Modes") ]
| The macro `define-minor-mode' offers a convenient way of implementing a
| mode in one self-contained definition.
`----

Bye,
Tassilo

Re: Gnus and new mail notification

[Yuri D'Elia]

> gnus-notify.el is available at:
>
>   http://www.thregr.org/~wavexx/hacks/gnus-notify.el

I've updated the library:

  http://www.thregr.org/~wavexx/hacks/gnus-desktop-notify/

as suggested. So many configurable options, so little time! ;)

Re: Gnus and new mail notification

[Philipp Haselwarter]

I found that

,----
| (gnus-group-unread (car g))
`----
sometimes yields nil, resulting in

,----
| let*: Wrong type argument: number-or-marker-p, nil
| 
| Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
|   +(3 nil)
|   (let* ((name (gnus-info-group g)) (unread (gnus-group-unread (car g)))
|   (count (+ read unread))))
`----

Initially I wasn't able to reproduce the behaviour but yesterday and
today it reoccurred, I wasn't able to track it down though.

Anyways, here's what I did to work around it:

--8<---------------cut here---------------start------------->8---
commit 6483c4b075539db1880c5d8a834caf7c9e902b1d (HEAD, refs/heads/check_count)
Author: Philipp Haselwarter <philipp.haselwarter@gmx.de>
Date:   Thu Dec 30 16:04:36 2010 +0100

    [Bugfix] gnus-desktop-notify-check
    
    Make `gnus-desktop-notify-check' more robust to another data inconsistency:
    `(gnus-group-unread (car g))' sometimes yields nil, causing
    `(count (+ read unread))' to fail.
    
    The fix returns 0 instead of nil and uses `name' instead of `(car g)'.

	Modified gnus-desktop-notify.el
diff --git a/gnus-desktop-notify.el b/gnus-desktop-notify.el
index 5aef4bb..2ec8cbb 100644
--- a/gnus-desktop-notify.el
+++ b/gnus-desktop-notify.el
@@ -199,7 +199,7 @@ with the behavior defined by `gnus-desktop-notify-send-mode'."
 		     (cdr (gnus-info-read g)))) )
 	(when read
 	  (let* ( (name (gnus-info-group g))
-		  (unread (gnus-group-unread (car g)))
+		  (unread (or (gnus-group-unread name) 0))
 		  (count (+ read unread))
 		  (old-count (cdr (assoc name gnus-desktop-notify-counts)))
 		  (notify (gnus-group-find-parameter name 'group-notify)) )
--8<---------------cut here---------------end--------------->8---



Furthermore, the markup you use in `gnus-desktop-notify-send':
,----
| (format "<br/><tt> <b>%d</b>:<b>%s</b></tt>"
`----
does not work at all with notify-send for me, it just gets displayed
literally, which is not-so-pretty..
,----
| % notify-send -v
| notify-send 0.5.2
`----



-- 
Philipp Haselwarter

Re: Gnus and new mail notification

[Thierry Volpiatto]

Richard Riley <rileyrg@googlemail.com> writes:

> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>
>> Richard Riley <rileyrg@googlemail.com> writes:
>>
>>> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>>>
>>>> Richard Riley <rileyrg@googlemail.com> writes:
>>>>
>>>>> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>>>>>
>>>>>> Richard Riley <rileyrg@googlemail.com> writes:
>>>>>>
>>>>>>> Yuri D'Elia <wavexx@users.sf.net> writes:
>>>>>>>
>>>>>>>> On Sun, 26 Dec 2010 00:19:42 +0100, Richard Riley wrote:
>>>>>>>>>> As soon as you use splitting or virtual groups, an external process
>>>>>>>>>> becomes useless (for instance, I have several rules that split messages
>>>>>>>>>> into groups that I ignore).
>>>>>>>>>
>>>>>>>>> Not if you dont use the demon and then split when you hit g. In other
>>>>>>>>> words you only fetch your mail when gnubiff or something similar tells
>>>>>>>>> you that you have new mail.
>>>>>>>>
>>>>>>>> Concrete example: if splitting includes spam rules, gnubiff will notify
>>>>>>>> you of spam too.
>>>>>>>>
>>>>>>>
>>>>>>> Yes that is most certainly true. Since I use googlemail I'm kind of
>>>>>>> spoiled as their spam filtering server side is pretty good these days
>>>>>>> (that and my spam-split set up doesnt work anymore on NoGnus) and so I
>>>>>>> turned off client side "spam-split"ting.
>>>>>>
>>>>>> If you use gmail, you can have easy mail notification with:
>>>>>>
>>>>>> https://mail.google.com/mail/feed/atom
>>>>>>
>>>>>> It give you an xml buffer you have to parse.
>>>>>>
>>>>>> A library exists on emacswiki for this, don't remember the name, it
>>>>>> didn't work for me so i wrote small code for this for my personal use, i
>>>>>> can send it if interested.
>>>>>> Of course if one use gnus-demon, it's non--sense to use this.
>>>>>
>>>>> Just as an FYI to the OP if new to Gnus, I have found the best set up
>>>>> for me with Gnus is dovecot locally fed by offlineimap which is run as a
>>>>> cron job every half hour or so.
>>>> I use here offlineimap.el that is started each time i start gnus.
>>>> http://julien.danjou.info/offlineimap-el.html
>>>> I think that coupled with a gmail notification is better than a
>>>> cronjob.
>>>
>>> I dont think it is since the benefit of my way is I dont need gnus
>>> running to see email notifications.
>> Me too ;-) See above
>>
>> Gnus is stopped.
>>
>> 1) I call async https://mail.google.com/mail/feed/atom every five
>> minutes.
>>
>> 2) When i am notified of a new email, i run Gnus who run offlineimap.
>
> Typo : sacrilege I know, but I mean emacs ;)
?

> I might try your way just as an academic exercise at one stage.
>
> You still need to manually run offlineimap in emacs though
No:
(add-hook 'gnus-before-startup-hook 'offlineimap)
 
> whereas mine
> just happens and I get informed as and when offlineimap has done its job
> so I can see the mail instantly!
Instantly every time your cron job have run.
My mail notification system watch directly the gmail server, it doesn't
depend of what offlineimap fetch.


> I use Mail Notification 5.4 to then
> preview whether to bother firing up gnus and fetching (instantly) from
> my local dovecot. My offlineimap config handles multiple accounts too.

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: Gnus and new mail notification

[Richard Riley]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> Richard Riley <rileyrg@googlemail.com> writes:
>
>> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>>
>>> Richard Riley <rileyrg@googlemail.com> writes:
>>>
>>>> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>>>>
>>>>> Richard Riley <rileyrg@googlemail.com> writes:
>>>>>
>>>>>> Yuri D'Elia <wavexx@users.sf.net> writes:
>>>>>>
>>>>>>> On Sun, 26 Dec 2010 00:19:42 +0100, Richard Riley wrote:
>>>>>>>>> As soon as you use splitting or virtual groups, an external process
>>>>>>>>> becomes useless (for instance, I have several rules that split messages
>>>>>>>>> into groups that I ignore).
>>>>>>>>
>>>>>>>> Not if you dont use the demon and then split when you hit g. In other
>>>>>>>> words you only fetch your mail when gnubiff or something similar tells
>>>>>>>> you that you have new mail.
>>>>>>>
>>>>>>> Concrete example: if splitting includes spam rules, gnubiff will notify
>>>>>>> you of spam too.
>>>>>>>
>>>>>>
>>>>>> Yes that is most certainly true. Since I use googlemail I'm kind of
>>>>>> spoiled as their spam filtering server side is pretty good these days
>>>>>> (that and my spam-split set up doesnt work anymore on NoGnus) and so I
>>>>>> turned off client side "spam-split"ting.
>>>>>
>>>>> If you use gmail, you can have easy mail notification with:
>>>>>
>>>>> https://mail.google.com/mail/feed/atom
>>>>>
>>>>> It give you an xml buffer you have to parse.
>>>>>
>>>>> A library exists on emacswiki for this, don't remember the name, it
>>>>> didn't work for me so i wrote small code for this for my personal use, i
>>>>> can send it if interested.
>>>>> Of course if one use gnus-demon, it's non--sense to use this.
>>>>
>>>> Just as an FYI to the OP if new to Gnus, I have found the best set up
>>>> for me with Gnus is dovecot locally fed by offlineimap which is run as a
>>>> cron job every half hour or so.
>>> I use here offlineimap.el that is started each time i start gnus.
>>> http://julien.danjou.info/offlineimap-el.html
>>> I think that coupled with a gmail notification is better than a
>>> cronjob.
>>
>> I dont think it is since the benefit of my way is I dont need gnus
>> running to see email notifications.
> Me too ;-) See above
>
> Gnus is stopped.
>
> 1) I call async https://mail.google.com/mail/feed/atom every five
> minutes.
>
> 2) When i am notified of a new email, i run Gnus who run offlineimap.

Typo : sacrilege I know, but I mean emacs ;)

I might try your way just as an academic exercise at one stage.

You still need to manually run offlineimap in emacs though whereas mine
just happens and I get informed as and when offlineimap has done its job
so I can see the mail instantly! I use Mail Notification 5.4 to then
preview whether to bother firing up gnus and fetching (instantly) from
my local dovecot. My offlineimap config handles multiple accounts too.

Re: Gnus and new mail notification

[Thierry Volpiatto]

Richard Riley <rileyrg@googlemail.com> writes:

> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>
>> Richard Riley <rileyrg@googlemail.com> writes:
>>
>>> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>>>
>>>> Richard Riley <rileyrg@googlemail.com> writes:
>>>>
>>>>> Yuri D'Elia <wavexx@users.sf.net> writes:
>>>>>
>>>>>> On Sun, 26 Dec 2010 00:19:42 +0100, Richard Riley wrote:
>>>>>>>> As soon as you use splitting or virtual groups, an external process
>>>>>>>> becomes useless (for instance, I have several rules that split messages
>>>>>>>> into groups that I ignore).
>>>>>>>
>>>>>>> Not if you dont use the demon and then split when you hit g. In other
>>>>>>> words you only fetch your mail when gnubiff or something similar tells
>>>>>>> you that you have new mail.
>>>>>>
>>>>>> Concrete example: if splitting includes spam rules, gnubiff will notify
>>>>>> you of spam too.
>>>>>>
>>>>>
>>>>> Yes that is most certainly true. Since I use googlemail I'm kind of
>>>>> spoiled as their spam filtering server side is pretty good these days
>>>>> (that and my spam-split set up doesnt work anymore on NoGnus) and so I
>>>>> turned off client side "spam-split"ting.
>>>>
>>>> If you use gmail, you can have easy mail notification with:
>>>>
>>>> https://mail.google.com/mail/feed/atom
>>>>
>>>> It give you an xml buffer you have to parse.
>>>>
>>>> A library exists on emacswiki for this, don't remember the name, it
>>>> didn't work for me so i wrote small code for this for my personal use, i
>>>> can send it if interested.
>>>> Of course if one use gnus-demon, it's non--sense to use this.
>>>
>>> Just as an FYI to the OP if new to Gnus, I have found the best set up
>>> for me with Gnus is dovecot locally fed by offlineimap which is run as a
>>> cron job every half hour or so.
>> I use here offlineimap.el that is started each time i start gnus.
>> http://julien.danjou.info/offlineimap-el.html
>> I think that coupled with a gmail notification is better than a
>> cronjob.
>
> I dont think it is since the benefit of my way is I dont need gnus
> running to see email notifications.
Me too ;-) See above

Gnus is stopped.

1) I call async https://mail.google.com/mail/feed/atom every five
minutes.

2) When i am notified of a new email, i run Gnus who run offlineimap.

> Emacs/Gnus just dont do "async" well
> and for me its not its job to run offlineimap which isnt necessarily the
> quickest anyway. Still horses for courses and an interesting mix of
> approaches ;)

>>
>>> nnir search works really well and of
>>> course there are then no performance or bandwidth issues with Gnus
>>> talking imap with remote gmail servers. Plus you have a local copy of
>>> your mail. Here is one "how to" for the set up:
>>>
>>> http://sachachua.com/blog/2008/05/geek-how-to-use-offlineimap-and-the-dovecot-mail-server-to-read-your-gmail-in-emacs-efficiently/
>>> http://tinyurl.com/26cwmok
>>
>> I have also started to use dovecot/offlineimap, however it's was not so
>> easy to configure dovecot, especially the mail_location, what is
>> described in sacha blog is deprecated.
>>
>> So here i use for gmail:
>> ,----[ dovecot config ]
>> | mail_location = maildir:~/Maildir:LAYOUT=fs:INBOX=~/Maildir/INBOX
>> `----
>> Hope that's help
>
> I use multiple virtual users to handle my different gmail accounts. I
> can share the set up if anyone is interested.

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: Gnus and new mail notification

[Richard Riley]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> Richard Riley <rileyrg@googlemail.com> writes:
>
>> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>>
>>> Richard Riley <rileyrg@googlemail.com> writes:
>>>
>>>> Yuri D'Elia <wavexx@users.sf.net> writes:
>>>>
>>>>> On Sun, 26 Dec 2010 00:19:42 +0100, Richard Riley wrote:
>>>>>>> As soon as you use splitting or virtual groups, an external process
>>>>>>> becomes useless (for instance, I have several rules that split messages
>>>>>>> into groups that I ignore).
>>>>>>
>>>>>> Not if you dont use the demon and then split when you hit g. In other
>>>>>> words you only fetch your mail when gnubiff or something similar tells
>>>>>> you that you have new mail.
>>>>>
>>>>> Concrete example: if splitting includes spam rules, gnubiff will notify
>>>>> you of spam too.
>>>>>
>>>>
>>>> Yes that is most certainly true. Since I use googlemail I'm kind of
>>>> spoiled as their spam filtering server side is pretty good these days
>>>> (that and my spam-split set up doesnt work anymore on NoGnus) and so I
>>>> turned off client side "spam-split"ting.
>>>
>>> If you use gmail, you can have easy mail notification with:
>>>
>>> https://mail.google.com/mail/feed/atom
>>>
>>> It give you an xml buffer you have to parse.
>>>
>>> A library exists on emacswiki for this, don't remember the name, it
>>> didn't work for me so i wrote small code for this for my personal use, i
>>> can send it if interested.
>>> Of course if one use gnus-demon, it's non--sense to use this.
>>
>> Just as an FYI to the OP if new to Gnus, I have found the best set up
>> for me with Gnus is dovecot locally fed by offlineimap which is run as a
>> cron job every half hour or so.
> I use here offlineimap.el that is started each time i start gnus.
> http://julien.danjou.info/offlineimap-el.html
> I think that coupled with a gmail notification is better than a
> cronjob.

I dont think it is since the benefit of my way is I dont need gnus
running to see email notifications. Emacs/Gnus just dont do "async" well
and for me its not its job to run offlineimap which isnt necessarily the
quickest anyway. Still horses for courses and an interesting mix of
approaches ;)

>
>> nnir search works really well and of
>> course there are then no performance or bandwidth issues with Gnus
>> talking imap with remote gmail servers. Plus you have a local copy of
>> your mail. Here is one "how to" for the set up:
>>
>> http://sachachua.com/blog/2008/05/geek-how-to-use-offlineimap-and-the-dovecot-mail-server-to-read-your-gmail-in-emacs-efficiently/
>> http://tinyurl.com/26cwmok
>
> I have also started to use dovecot/offlineimap, however it's was not so
> easy to configure dovecot, especially the mail_location, what is
> described in sacha blog is deprecated.
>
> So here i use for gmail:
> ,----[ dovecot config ]
> | mail_location = maildir:~/Maildir:LAYOUT=fs:INBOX=~/Maildir/INBOX
> `----
> Hope that's help

I use multiple virtual users to handle my different gmail accounts. I
can share the set up if anyone is interested.

Re: Gnus and new mail notification

[Thierry Volpiatto]

Richard Riley <rileyrg@googlemail.com> writes:

> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>
>> Richard Riley <rileyrg@googlemail.com> writes:
>>
>>> Yuri D'Elia <wavexx@users.sf.net> writes:
>>>
>>>> On Sun, 26 Dec 2010 00:19:42 +0100, Richard Riley wrote:
>>>>>> As soon as you use splitting or virtual groups, an external process
>>>>>> becomes useless (for instance, I have several rules that split messages
>>>>>> into groups that I ignore).
>>>>>
>>>>> Not if you dont use the demon and then split when you hit g. In other
>>>>> words you only fetch your mail when gnubiff or something similar tells
>>>>> you that you have new mail.
>>>>
>>>> Concrete example: if splitting includes spam rules, gnubiff will notify
>>>> you of spam too.
>>>>
>>>
>>> Yes that is most certainly true. Since I use googlemail I'm kind of
>>> spoiled as their spam filtering server side is pretty good these days
>>> (that and my spam-split set up doesnt work anymore on NoGnus) and so I
>>> turned off client side "spam-split"ting.
>>
>> If you use gmail, you can have easy mail notification with:
>>
>> https://mail.google.com/mail/feed/atom
>>
>> It give you an xml buffer you have to parse.
>>
>> A library exists on emacswiki for this, don't remember the name, it
>> didn't work for me so i wrote small code for this for my personal use, i
>> can send it if interested.
>> Of course if one use gnus-demon, it's non--sense to use this.
>
> Just as an FYI to the OP if new to Gnus, I have found the best set up
> for me with Gnus is dovecot locally fed by offlineimap which is run as a
> cron job every half hour or so.
I use here offlineimap.el that is started each time i start gnus.
http://julien.danjou.info/offlineimap-el.html
I think that coupled with a gmail notification is better than a cronjob.
 
> nnir search works really well and of
> course there are then no performance or bandwidth issues with Gnus
> talking imap with remote gmail servers. Plus you have a local copy of
> your mail. Here is one "how to" for the set up:
>
> http://sachachua.com/blog/2008/05/geek-how-to-use-offlineimap-and-the-dovecot-mail-server-to-read-your-gmail-in-emacs-efficiently/
> http://tinyurl.com/26cwmok

I have also started to use dovecot/offlineimap, however it's was not so
easy to configure dovecot, especially the mail_location, what is
described in sacha blog is deprecated.

So here i use for gmail:
,----[ dovecot config ]
| mail_location = maildir:~/Maildir:LAYOUT=fs:INBOX=~/Maildir/INBOX
`----
Hope that's help

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: Gnus and new mail notification

[Philipp Haselwarter]

I found this one quite useful, too (notmuch makes searches *really* fast):
http://roland.entierement.nu/blog/2010/09/08/gnus-dovecot-offlineimap-search-a-howto.html


-- 
Philipp Haselwarter

Re: Gnus and new mail notification

[Richard Riley]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> Richard Riley <rileyrg@googlemail.com> writes:
>
>> Yuri D'Elia <wavexx@users.sf.net> writes:
>>
>>> On Sun, 26 Dec 2010 00:19:42 +0100, Richard Riley wrote:
>>>>> As soon as you use splitting or virtual groups, an external process
>>>>> becomes useless (for instance, I have several rules that split messages
>>>>> into groups that I ignore).
>>>>
>>>> Not if you dont use the demon and then split when you hit g. In other
>>>> words you only fetch your mail when gnubiff or something similar tells
>>>> you that you have new mail.
>>>
>>> Concrete example: if splitting includes spam rules, gnubiff will notify
>>> you of spam too.
>>>
>>
>> Yes that is most certainly true. Since I use googlemail I'm kind of
>> spoiled as their spam filtering server side is pretty good these days
>> (that and my spam-split set up doesnt work anymore on NoGnus) and so I
>> turned off client side "spam-split"ting.
>
> If you use gmail, you can have easy mail notification with:
>
> https://mail.google.com/mail/feed/atom
>
> It give you an xml buffer you have to parse.
>
> A library exists on emacswiki for this, don't remember the name, it
> didn't work for me so i wrote small code for this for my personal use, i
> can send it if interested.
> Of course if one use gnus-demon, it's non--sense to use this.

Just as an FYI to the OP if new to Gnus, I have found the best set up
for me with Gnus is dovecot locally fed by offlineimap which is run as a
cron job every half hour or so. nnir search works really well and of
course there are then no performance or bandwidth issues with Gnus
talking imap with remote gmail servers. Plus you have a local copy of
your mail. Here is one "how to" for the set up:

http://sachachua.com/blog/2008/05/geek-how-to-use-offlineimap-and-the-dovecot-mail-server-to-read-your-gmail-in-emacs-efficiently/
http://tinyurl.com/26cwmok

regards

r.

Re: Gnus and new mail notification

[Thierry Volpiatto]

Richard Riley <rileyrg@googlemail.com> writes:

> Yuri D'Elia <wavexx@users.sf.net> writes:
>
>> On Sun, 26 Dec 2010 00:19:42 +0100, Richard Riley wrote:
>>>> As soon as you use splitting or virtual groups, an external process
>>>> becomes useless (for instance, I have several rules that split messages
>>>> into groups that I ignore).
>>>
>>> Not if you dont use the demon and then split when you hit g. In other
>>> words you only fetch your mail when gnubiff or something similar tells
>>> you that you have new mail.
>>
>> Concrete example: if splitting includes spam rules, gnubiff will notify
>> you of spam too.
>>
>
> Yes that is most certainly true. Since I use googlemail I'm kind of
> spoiled as their spam filtering server side is pretty good these days
> (that and my spam-split set up doesnt work anymore on NoGnus) and so I
> turned off client side "spam-split"ting.

If you use gmail, you can have easy mail notification with:

https://mail.google.com/mail/feed/atom

It give you an xml buffer you have to parse.

A library exists on emacswiki for this, don't remember the name, it
didn't work for me so i wrote small code for this for my personal use, i
can send it if interested.
Of course if one use gnus-demon, it's non--sense to use this.

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: Gnus and new mail notification

[Richard Riley]

Yuri D'Elia <wavexx@users.sf.net> writes:

> On Sun, 26 Dec 2010 00:19:42 +0100, Richard Riley wrote:
>>> As soon as you use splitting or virtual groups, an external process
>>> becomes useless (for instance, I have several rules that split messages
>>> into groups that I ignore).
>>
>> Not if you dont use the demon and then split when you hit g. In other
>> words you only fetch your mail when gnubiff or something similar tells
>> you that you have new mail.
>
> Concrete example: if splitting includes spam rules, gnubiff will notify
> you of spam too.
>

Yes that is most certainly true. Since I use googlemail I'm kind of
spoiled as their spam filtering server side is pretty good these days
(that and my spam-split set up doesnt work anymore on NoGnus) and so I
turned off client side "spam-split"ting.

regards

r.

Re: Gnus and new mail notification

[Philipp Haselwarter]

On Sun, 26 Dec 2010 19:26:09 +0100, Philipp Haselwarter said:
---8<---[snipped 6 lines]---8<---
PH> `gnus-notify-ignore-groups' could be added without much hassle, I
PH> might write a patch tomorrow if I get around to it.

Or simply use what is already there:

(setq gnus-parameters
      `(("spam"
         (group-notify . t))
        ))

Sorry for the noise, haven't fully recovered from yesterday's Christmas
party..


-- 
Philipp Haselwarter

Re: Gnus and new mail notification

[Philipp Haselwarter]

I find gnus-desktop-notify just fine; says what it's about and is not
yet in use.

Personally I do spam sorting server-side, so I'm not concerned about
getting notifications for groups I'm not interested in.
I guess a `gnus-notify-ignore-groups' could be added without much
hassle, I might write a patch tomorrow if I get around to it.


-- 
Philipp Haselwarter

Re: Gnus and new mail notification

[Yuri D'Elia]

On Sun, 26 Dec 2010 00:19:42 +0100, Richard Riley wrote:
>> As soon as you use splitting or virtual groups, an external process
>> becomes useless (for instance, I have several rules that split messages
>> into groups that I ignore).
>
> Not if you dont use the demon and then split when you hit g. In other
> words you only fetch your mail when gnubiff or something similar tells
> you that you have new mail.

Concrete example: if splitting includes spam rules, gnubiff will notify
you of spam too.

Re: Gnus and new mail notification

[Richard Riley]

Yuri D'Elia <wavexx@users.sf.net> writes:

> On Sat, 25 Dec 2010 21:31:43 +0100, Richard Riley wrote:
>> I'm interested how this helps - I think I'm missing something. Since
>> this can only work in Gnus when Gnus sees new mail what purpose does it
>> server since Gnus has already fetched the mail : isnt a third party
>> imap/maildir asynchronous monitor a better solution for this external
>> notification process?
>
> As soon as you use splitting or virtual groups, an external process
> becomes useless (for instance, I have several rules that split messages
> into groups that I ignore).

Not if you dont use the demon and then split when you hit g. In other
words you only fetch your mail when gnubiff or something similar tells
you that you have new mail.

That said I must try the daemon again as I havent used it for a while.

Re: Gnus and new mail notification

[Yuri D'Elia]

On Sat, 25 Dec 2010 21:31:43 +0100, Richard Riley wrote:
> I'm interested how this helps - I think I'm missing something. Since
> this can only work in Gnus when Gnus sees new mail what purpose does it
> server since Gnus has already fetched the mail : isnt a third party
> imap/maildir asynchronous monitor a better solution for this external
> notification process?

As soon as you use splitting or virtual groups, an external process
becomes useless (for instance, I have several rules that split messages
into groups that I ignore).

Of course, this only makes sense if you fetch mail/news regularly with
gnus-demon and leave gnus running.

Re: Gnus and new mail notification

[Tassilo Horn]

Richard Riley <rileyrg@googlemail.com> writes:

Hi Rich,

> I'm interested how this helps - I think I'm missing something.  Since
> this can only work in Gnus when Gnus sees new mail what purpose does
> it server since Gnus has already fetched the mail

Yes.  It makes only sense as soon as you let Gnus fetch new mail
regularly, like by using demons.

Bye,
Tassilo

Re: Gnus and new mail notification

[Richard Riley]

Yuri D'Elia <wavexx@users.sf.net> writes:

> I wasn't happy with the existing new mail notification scripts that I've
> found on emacswiki.
>
> I've put together a new script, called "gnus-notify"[1], that can call
> any arbitrary program when new messages are received. The default uses
> the 'notify-send' program (part of libnotify's library) which creates
> little popup messages. This is especially useful if you have virtual
> desktops and leave Gnus running with gnus-demon.
>
> The result (showing Gnus + awesomewm + libnotify-bin on Debian) is shown
> here:
>
>   http://www.thregr.org/~wavexx/hacks/gnus-notify.png
>
> You can also do arbitrary stuff by either setting a different
> executable, or supplying an entirely new notification function.
> Simply read the commentary in the source.
>
> gnus-notify.el is available at:
>
>   http://www.thregr.org/~wavexx/hacks/gnus-notify.el
>
> Merry christmas :)
>
> [1] I know there's already a gnus-notify.el script, but I wasn't able to
>     come up with a better name.
>

I'm interested how this helps - I think I'm missing something. Since
this can only work in Gnus when Gnus sees new mail what purpose does it
server since Gnus has already fetched the mail : isnt a third party
imap/maildir asynchronous monitor a better solution for this external
notification process?

Also using the same name is somewhat silly since it will clash if
packaged in ELPA or something especially as it does something totally
different to gnus-notify : what about gnus-external-notify?

regards

r.

Re: Gnus and new mail notification

[e20100633]

Hello,

Yuri D'Elia <wavexx@users.sf.net> writes:

> [snip (17 lines)]
> gnus-notify.el is available at:
>
>   http://www.thregr.org/~wavexx/hacks/gnus-notify.el

Well, thank you very much, very usefull.

> [1] I know there's already a gnus-notify.el script, but I wasn't able to
>     come up with a better name.

Maybe something like : gnus-biff.el ?

Regards,

-- 
~ #ID: e20100633 <e20100633()inbox!lv> #TTY: 9-8M 4554
~ TYPE 1707-A3 S/N L3-M2812 SLACKWARE 13.0 RLU #527034
------------------------------------------------{,_,">
They say that an incubus whose initial is F- sometimes
makes women feel sensitive.          --- Play NetHack!