Restricting frequency of 'g'

Restricting frequency of 'g'

[Russ Allbery]

I've noticed a bad habit in myself (and I'm betting I'm not the only one)
where I'll press g in a Gnus group buffer to check for new mail whenever I
pass by the screen in which Gnus is running or whenever I'm waiting for
something else, even for a moment.  And then I get sucked back into my
mail, including often a lot of traffic that I don't need to see right
then.

Does anyone have a good recipe for having Gnus remember the last time I
checked for new mail and to force me to jump through some hoop if it's
been less than a configurable amount of time?  My guess is that it
wouldn't be horribly difficult to do this in elisp by rebinding g, but
it's a bit beyond my personal skill.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: Restricting frequency of 'g'

[Bill O'Connor]

Russ Allbery <rra@stanford.edu> writes:

> I've noticed a bad habit in myself (and I'm betting I'm not the only one)
> where I'll press g in a Gnus group buffer to check for new mail whenever I
> pass by the screen in which Gnus is running or whenever I'm waiting for
> something else, even for a moment.  And then I get sucked back into my
> mail, including often a lot of traffic that I don't need to see right
> then.
>
> Does anyone have a good recipe for having Gnus remember the last time I
> checked for new mail and to force me to jump through some hoop if it's
> been less than a configurable amount of time?  My guess is that it
> wouldn't be horribly difficult to do this in elisp by rebinding g, but
> it's a bit beyond my personal skill.
>
> -- 
> Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

I just let gnus do it for me every 20 minutes.  

(gnus-demon-add-handler 'gnus-demon-scan-and-update 20 nil)
(setq gnus-use-demon t)
(gnus-demon-init)

Re: Restricting frequency of 'g'

[Russ Allbery]

Bill O'Connor <billyoc@gmail.com> writes:

> I just let gnus do it for me every 20 minutes.  
>
> (gnus-demon-add-handler 'gnus-demon-scan-and-update 20 nil)
> (setq gnus-use-demon t)
> (gnus-demon-init)

Hm.  I suppose I could rebind g to something that complains at me and turn
the above on, and that would pretty much get the behavior that I want.
Thanks!

However, I don't have that function in 5.11 (gnus-demon-scan-and-update),
as near as I can tell.  I'd rather not update all of Gnus to the current
development version; is it easily extractable?  And can I set up different
schedules for different levels of subscribedness?

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: Restricting frequency of 'g'

[John SJ Anderson]

Russ Allbery <rra@stanford.edu> writes:

> Does anyone have a good recipe for having Gnus remember the last time I
> checked for new mail and to force me to jump through some hoop if it's
> been less than a configurable amount of time?  

  I had the same problem; so I came up with this and then retrained
  myself to hit 'F6' instead of 'g'.

(defvar jsja/last-mail-check (float-time)
  "last time i checked mail via magic key")
(defvar jsja/mail-check-interval (* 60 5)
  "how long i should wait before checking mail")
(defun jsja/switch-to-gnus ()
  "Bring Gnus *Group* buffer to front, starting Gnus if needed"
  (interactive)
  (if (or (not (fboundp 'gnus-alive-p))
          (not (gnus-alive-p)))
      (gnus)
    (switch-to-buffer "*Group*")
    (delete-other-windows)
    (setq next-mail-check (+ jsja/last-mail-check jsja/mail-check-interval))
    (if (< (float-time) next-mail-check)
        (message (concat 
                  "no gnus is good news ("  
                  (int-to-string (floor (- next-mail-check (float-time))))
                  " seconds until next check allowed)" ))
      (gnus-group-get-new-news 1)
      (setq jsja/last-mail-check (float-time)))))
(global-set-key (kbd "<f6>")  'jsja/switch-to-gnus)



john.
-- 
I WILL NOT DEMAND WHAT I'M WORTH
I WILL NOT DEMAND WHAT I'M WORTH
I WILL NOT DEMAND WHAT I'M WORTH
	Bart Simpson on chalkboard in episode 5F14

Re: Restricting frequency of 'g'

[Russ Allbery]

John SJ Anderson <genehack@genehack.org> writes:

>   I had the same problem; so I came up with this and then retrained
>   myself to hit 'F6' instead of 'g'.
>
> (defvar jsja/last-mail-check (float-time)
>   "last time i checked mail via magic key")
> (defvar jsja/mail-check-interval (* 60 5)
>   "how long i should wait before checking mail")
> (defun jsja/switch-to-gnus ()
>   "Bring Gnus *Group* buffer to front, starting Gnus if needed"
>   (interactive)
>   (if (or (not (fboundp 'gnus-alive-p))
>           (not (gnus-alive-p)))
>       (gnus)
>     (switch-to-buffer "*Group*")
>     (delete-other-windows)
>     (setq next-mail-check (+ jsja/last-mail-check jsja/mail-check-interval))
>     (if (< (float-time) next-mail-check)
>         (message (concat 
>                   "no gnus is good news ("  
>                   (int-to-string (floor (- next-mail-check (float-time))))
>                   " seconds until next check allowed)" ))
>       (gnus-group-get-new-news 1)
>       (setq jsja/last-mail-check (float-time)))))
> (global-set-key (kbd "<f6>")  'jsja/switch-to-gnus)

Thanks!  This gave me the logic that I wanted.  I'm now using this (I
suppose I'm supposed to use rra/ instead of rra- as a prefix for private
functions, aren't I?):

;; Use this function instead of gnus-group-get-new-news as the action for g.
;; It changes the level of subscribedness that it checks based on how long
;; it's been since the previous check and tries to throttle checking mail too
;; often.
(defvar rra-last-mail-important-check (float-time)
  "The last time I checked mail in important groups.")
(defvar rra-last-mail-normal-check (float-time)
  "The last time I checked mail in normal groups.")
(defvar rra-last-mail-low-check (float-time)
  "The last time I checked mail in low-priority groups.")
(defvar rra-mail-important-check-interval (* 60 15)
  "How long I'm required to wait before checking mail in important groups.")
(defvar rra-mail-normal-check-interval (* 60 30)
  "How long I'm required to wait before checking mail in normal groups.")
(defvar rra-mail-low-check-interval (* 60 60)
  "How long I'm required to wait before checking mail in low-priority groups.")
(defun rra-timed-gnus-group-get-new-news ()
  "Get newly arrived articles based on the interval since the last time I've
checked for new articles."
  (interactive)
  (cond
   ((> (float-time) (+ rra-last-mail-low-check rra-mail-low-check-interval))
    (gnus-group-get-new-news)
    (setq rra-last-mail-low-check (float-time))
    (setq rra-last-mail-normal-check (float-time))
    (setq rra-last-mail-important-check (float-time)))
   ((> (float-time) (+ rra-last-mail-normal-check
                       rra-mail-normal-check-interval))
    (gnus-group-get-new-news 3)
    (setq rra-last-mail-normal-check (float-time))
    (setq rra-last-mail-important-check (float-time)))
   ((> (float-time) (+ rra-last-mail-important-check
                       rra-mail-important-check-interval))
    (gnus-group-get-new-news 1)
    (setq rra-last-mail-important-check (float-time)))
   (t
    (let ((next-check (+ rra-last-mail-important-check
                         rra-mail-important-check-interval)))
      (message (concat "No gnus is good news ("
                       (int-to-string (floor (- next-check (float-time))))
                       " seconds until check allowed)"))))))

and rebinding "g" to rra-timed-gnus-group-get-new-news.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: Restricting frequency of 'g'

[jidanni]

Your time-limited and cron-job-style assisted approaches are
artificial.

I share not your pain, as I use noffle, getmail, so whatever is to be
fetched is already on the local disk, just a folder away.

However, an accidental "g" press would still send the game into
halftime for me, if it weren't for my

(defun jidanni-gnus-group-get-new-rss-news()
  "Sorry attempt to seperate out painful RSS fetching."
  (let ((gnus-activate-foreign-newsgroups 5))
    (gnus-group-get-new-news)))
(define-key gnus-group-mode-map "v"
  (lambda ()
    (interactive)
    (jidanni-gnus-group-get-new-rss-news)))

and my having put each RSS on level 5 etc. etc. Barf.
Yes, one could make the batch script, OK, some other day.

Re: Restricting frequency of 'g'

[John SJ Anderson]

jidanni@jidanni.org writes:

> Your time-limited and cron-job-style assisted approaches are
> artificial.

  Yes, but at least for me, the issue isn't that fetching mail takes a
  long time -- the issue is that I do it far too frequently (the "rat
  hitting the button to see if a crack pellet comes out" phenomenon). 

  By setting things up so that I get reminded that I already checked
  email less than $INTERVAL $UNITS ago, I'm hoping that I can break
  myself of this foul habit, and get some Real Work done, instead of
  checking for new shiny distractions coming down the mail pipe.

chrs,
john.
-- 
My life needs a rewind/erase button.
		  -- Calvin

Re: Restricting frequency of 'g'

[Russ Allbery]

John SJ Anderson <genehack@genehack.org> writes:
> jidanni@jidanni.org writes:

>> Your time-limited and cron-job-style assisted approaches are
>> artificial.
>
>   Yes, but at least for me, the issue isn't that fetching mail takes a
>   long time -- the issue is that I do it far too frequently (the "rat
>   hitting the button to see if a crack pellet comes out" phenomenon). 

Exactly.  The problem that I'm solving is not a software problem.  It's a
brain crutch.  This particular limitation was inspired by reading about
Inbox Zero and realizing the degree to which I constantly check my e-mail,
have great difficulty not immediately processing mail as soon as I see it,
and have great difficulty not replying to mail as soon as I've processed
it, all of which distracts me from getting done the things I actually need
to work on.

>   By setting things up so that I get reminded that I already checked
>   email less than $INTERVAL $UNITS ago, I'm hoping that I can break
>   myself of this foul habit, and get some Real Work done, instead of
>   checking for new shiny distractions coming down the mail pipe.

It's remarkable how well this has worked after only one day.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

a Gnus biff (was: Restricting frequency of 'g')

[Ted Zlatanov]

On Mon, 07 Apr 2008 20:41:23 -0700 Russ Allbery <rra@stanford.edu> wrote: 

RA> John SJ Anderson <genehack@genehack.org> writes:
>> jidanni@jidanni.org writes:

>>> Your time-limited and cron-job-style assisted approaches are
>>> artificial.
>> 
>> Yes, but at least for me, the issue isn't that fetching mail takes a
>> long time -- the issue is that I do it far too frequently (the "rat
>> hitting the button to see if a crack pellet comes out" phenomenon). 

RA> Exactly.  The problem that I'm solving is not a software problem.  It's a
RA> brain crutch.  This particular limitation was inspired by reading about
RA> Inbox Zero and realizing the degree to which I constantly check my e-mail,
RA> have great difficulty not immediately processing mail as soon as I see it,
RA> and have great difficulty not replying to mail as soon as I've processed
RA> it, all of which distracts me from getting done the things I actually need
RA> to work on.

I hope my approach is helpful:

1) `g' in Gnus takes a loooong time (everything is fetched) so I only do
it every 1-2 hours, or when I leave for a few minutes.

2) I have an `i' alias that shows me what new messages have arrived
(it's a Perl script that speaks IMAP and Maildir).  It can even display
a particular message by number if I must see it right away.

3) I use M-g on a group if a new message is interesting and it will go
to that group, and I want to do something with that message.

Gnus could use something like (2), a biff command that just peeks in all
the mail sources and generates a quick summary, but you can't do
anything with it.  The command could even show the destination groups
for each message using the split rules.  With IMAP/POP3 and file-based
methods this is all fairly easy.

Ted

Re: a Gnus biff

[Wes Hardaker]

>>>>> "TZ" == Ted Zlatanov <tzz@lifelogs.com> writes:

TZ> 1) `g' in Gnus takes a loooong time (everything is fetched) so I only do
TZ> it every 1-2 hours, or when I leave for a few minutes.

I just switched IMAP servers to dovecot with maildir and checking for
new mail is now much much faster.  (now I have different issues, but
that's another story).

TZ> 2) I have an `i' alias that shows me what new messages have arrived
TZ> (it's a Perl script that speaks IMAP and Maildir).  It can even display
TZ> a particular message by number if I must see it right away.

I too have a script like that as well... It actually drives a desktop
superkaramab display that shows the to N incoming messages in various
folders so the list of incoming mail is always available to my eyes (and
I can call it from the command line if I'm ssh'ing in from somewhere
else).  It nicely summarizes all my mail in my important folders, which
I love.


The other option you didn't mention though is proper level setting.  Set
all your critical folders to priority 1, next to 2, ...  Then when you
need to check for critical mail do a '1 g' instead and that generally is
much faster.  My mailing list mail that I don't need to read on a
2-minute basis is levels 4 and beyond.  That way I only take the hit on
those once a day or so.
-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

Re: Restricting frequency of 'g'

[Dan Nicolaescu]

Russ Allbery <rra@stanford.edu> writes:

  > I've noticed a bad habit in myself (and I'm betting I'm not the only one)
  > where I'll press g in a Gnus group buffer to check for new mail whenever I
  > pass by the screen in which Gnus is running or whenever I'm waiting for
  > something else, even for a moment.  And then I get sucked back into my
  > mail, including often a lot of traffic that I don't need to see right
  > then.
  > 
  > Does anyone have a good recipe for having Gnus remember the last time I
  > checked for new mail and to force me to jump through some hoop if it's
  > been less than a configurable amount of time?  My guess is that it
  > wouldn't be horribly difficult to do this in elisp by rebinding g, but
  > it's a bit beyond my personal skill.

Someone posted a different solution for the same problem here (or
another gnus list): do not show new messages in groups is the number of
new message is under a certain threshold.  

I don't remember who it was, but maybe someone else does...

Re: Restricting frequency of 'g'

[Dan Nicolaescu]

Dan Nicolaescu <dann@ics.uci.edu> writes:

  > Russ Allbery <rra@stanford.edu> writes:
  > 
  >   > I've noticed a bad habit in myself (and I'm betting I'm not the only one)
  >   > where I'll press g in a Gnus group buffer to check for new mail whenever I
  >   > pass by the screen in which Gnus is running or whenever I'm waiting for
  >   > something else, even for a moment.  And then I get sucked back into my
  >   > mail, including often a lot of traffic that I don't need to see right
  >   > then.
  >   > 
  >   > Does anyone have a good recipe for having Gnus remember the last time I
  >   > checked for new mail and to force me to jump through some hoop if it's
  >   > been less than a configurable amount of time?  My guess is that it
  >   > wouldn't be horribly difficult to do this in elisp by rebinding g, but
  >   > it's a bit beyond my personal skill.
  > 
  > Someone posted a different solution for the same problem here (or
  > another gnus list): do not show new messages in groups is the number of
  > new message is under a certain threshold.  
  > 
  > I don't remember who it was, but maybe someone else does...

I found the article mentioned above:

http://article.gmane.org/gmane.emacs.gnus.general/60153

this looks like a nice feature to have in gnus...

Re: Restricting frequency of 'g'

[Reiner Steib]

On Wed, Apr 09 2008, Dan Nicolaescu wrote:
> Dan Nicolaescu <dann@ics.uci.edu> writes:
>   > Someone posted a different solution for the same problem here
>   > (or another gnus list): do not show new messages in groups is
>   > the number of new message is under a certain threshold.
>   > 
>   > I don't remember who it was, but maybe someone else does...
>
> I found the article mentioned above:
>
> http://article.gmane.org/gmane.emacs.gnus.general/60153

,----[ http://thread.gmane.org/gmane.emacs.gnus.general/60153 ]
| From: Mark Plaksin <happy <at> usg.edu>
| Subject: CODE: Hide groups with few unread articles
| Newsgroups: gmane.emacs.gnus.general
| Date: 2005-04-14 01:20:29 GMT
`----

> this looks like a nice feature to have in gnus...

The papers for Mark Plaksin are on file, so we could install his code.
We need some documentation as well and find suitable key bindings.

(Mark, sorry that this patch has been forgotten until now.)

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Restricting frequency of 'g'

[Mark Plaksin]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> On Wed, Apr 09 2008, Dan Nicolaescu wrote:
>
>> Dan Nicolaescu <dann@ics.uci.edu> writes:
>>   > Someone posted a different solution for the same problem here
>>   > (or another gnus list): do not show new messages in groups is
>>   > the number of new message is under a certain threshold.
>>   > 
>>   > I don't remember who it was, but maybe someone else does...
>>
>> I found the article mentioned above:
>>
>> http://article.gmane.org/gmane.emacs.gnus.general/60153
>
> ,----[ http://thread.gmane.org/gmane.emacs.gnus.general/60153 ]
> | From: Mark Plaksin <happy <at> usg.edu>
> | Subject: CODE: Hide groups with few unread articles
> | Newsgroups: gmane.emacs.gnus.general
> | Date: 2005-04-14 01:20:29 GMT
> `----
>
>> this looks like a nice feature to have in gnus...
>
> The papers for Mark Plaksin are on file, so we could install his code.
> We need some documentation as well and find suitable key bindings.
>
> (Mark, sorry that this patch has been forgotten until now.)

After submitting copyright papers I intended to clean up the code, write
docs, etc.  Insert excuses and apologies here.  I'll get it done in the
next week or three.

Re: Restricting frequency of 'g'

[Dan Nicolaescu]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

  > On Wed, Apr 09 2008, Dan Nicolaescu wrote:
  > > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > >   > Someone posted a different solution for the same problem here
  > >   > (or another gnus list): do not show new messages in groups is
  > >   > the number of new message is under a certain threshold.
  > >   > 
  > >   > I don't remember who it was, but maybe someone else does...
  > >
  > > I found the article mentioned above:
  > >
  > > http://article.gmane.org/gmane.emacs.gnus.general/60153
  > 
  > ,----[ http://thread.gmane.org/gmane.emacs.gnus.general/60153 ]
  > | From: Mark Plaksin <happy <at> usg.edu>
  > | Subject: CODE: Hide groups with few unread articles
  > | Newsgroups: gmane.emacs.gnus.general
  > | Date: 2005-04-14 01:20:29 GMT
  > `----
  > 
  > > this looks like a nice feature to have in gnus...
  > 
  > The papers for Mark Plaksin are on file, so we could install his code.
  > We need some documentation as well and find suitable key bindings.
  > 
  > (Mark, sorry that this patch has been forgotten until now.)

Any chance this can be installed before the 23.1 feature freeze?

Re: Restricting frequency of 'g'

[Reiner Steib]

On Sat, Apr 12 2008, Mark Plaksin wrote:

>> ,----[ http://thread.gmane.org/gmane.emacs.gnus.general/60153 ]
>> | From: Mark Plaksin <happy <at> usg.edu>
>> | Subject: CODE: Hide groups with few unread articles
>> | Newsgroups: gmane.emacs.gnus.general
>> | Date: 2005-04-14 01:20:29 GMT
>> `----
> After submitting copyright papers I intended to clean up the code, write
> docs, etc.  Insert excuses and apologies here.  I'll get it done in the
> next week or three.

On Tue, Jul 29 2008, Dan Nicolaescu wrote:

> Any chance this can be installed before the 23.1 feature freeze?

Marc, did you find time to do the code clean up?  If you can't submit
an updated patch withing the next days, would it make sense to install
the 2005 patch now and do the cleanup + docs during the Emacs feature
freeze.  (I suppose this is okay for the Emacs maintainers.)

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Restricting frequency of 'g'

[Dan Nicolaescu]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

  > On Sat, Apr 12 2008, Mark Plaksin wrote:
  > 
  > >> ,----[ http://thread.gmane.org/gmane.emacs.gnus.general/60153 ]
  > >> | From: Mark Plaksin <happy <at> usg.edu>
  > >> | Subject: CODE: Hide groups with few unread articles
  > >> | Newsgroups: gmane.emacs.gnus.general
  > >> | Date: 2005-04-14 01:20:29 GMT
  > >> `----
  > > After submitting copyright papers I intended to clean up the code, write
  > > docs, etc.  Insert excuses and apologies here.  I'll get it done in the
  > > next week or three.
  > 
  > On Tue, Jul 29 2008, Dan Nicolaescu wrote:
  > 
  > > Any chance this can be installed before the 23.1 feature freeze?
  > 
  > Marc, did you find time to do the code clean up?  If you can't submit
  > an updated patch withing the next days, would it make sense to install
  > the 2005 patch now and do the cleanup + docs during the Emacs feature
  > freeze.  (I suppose this is okay for the Emacs maintainers.)

Can this be installed now?  emacs-23.1 is out, but hopefully it can get
in for the 23.2 release... 

Re: Restricting frequency of 'g'

[Dan Nicolaescu]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> On Wed, Apr 09 2008, Dan Nicolaescu wrote:
>> Dan Nicolaescu <dann@ics.uci.edu> writes:
>>   > Someone posted a different solution for the same problem here
>>   > (or another gnus list): do not show new messages in groups is
>>   > the number of new message is under a certain threshold.
>>   > 
>>   > I don't remember who it was, but maybe someone else does...
>>
>> I found the article mentioned above:
>>
>> http://article.gmane.org/gmane.emacs.gnus.general/60153
>
> ,----[ http://thread.gmane.org/gmane.emacs.gnus.general/60153 ]
> | From: Mark Plaksin <happy <at> usg.edu>
> | Subject: CODE: Hide groups with few unread articles
> | Newsgroups: gmane.emacs.gnus.general
> | Date: 2005-04-14 01:20:29 GMT
> `----
>
>> this looks like a nice feature to have in gnus...
>
> The papers for Mark Plaksin are on file, so we could install his code.
> We need some documentation as well and find suitable key bindings.
>
> (Mark, sorry that this patch has been forgotten until now.)

Ping... 
Any reason not to install this patch?

Re: Restricting frequency of 'g'

[Lars Magne Ingebrigtsen]

Dan Nicolaescu <dann@gnu.org> writes:

> Any reason not to install this patch?

The functionality doesn't seem all that compelling...  Would many people
use it?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Restricting frequency of 'g'

[Russ Allbery]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> Dan Nicolaescu <dann@gnu.org> writes:

>> Any reason not to install this patch?

> The functionality doesn't seem all that compelling...  Would many people
> use it?

I absolutely swear by my implementation, although I wouldn't use the one
that you're responding to.  It's a really valuable tool in helping me
avoid the temptation to spend all day checking my mail.

;; Use this function instead of gnus-group-get-new-news as the action for g.
;; It changes the level of subscribedness that it checks based on how long
;; it's been since the previous check and tries to throttle checking mail too
;; often.
(defvar rra-last-mail-important-check (float-time)
  "The last time I checked mail in important groups.")
(defvar rra-last-mail-normal-check (float-time)
  "The last time I checked mail in normal groups.")
(defvar rra-last-mail-low-check (float-time)
  "The last time I checked mail in low-priority groups.")
(defvar rra-mail-important-check-interval (* 60 15)
  "How long I'm required to wait before checking mail in important groups.")
(defvar rra-mail-normal-check-interval (* 60 30)
  "How long I'm required to wait before checking mail in normal groups.")
(defvar rra-mail-low-check-interval (* 60 60)
  "How long I'm required to wait before checking mail in low-priority groups.")
(defun rra-timed-gnus-group-get-new-news ()
  "Get newly arrived articles based on the interval since the last time I've
checked for new articles."
  (interactive)
  (cond
   ((> (float-time) (+ rra-last-mail-low-check rra-mail-low-check-interval))
    (gnus-group-get-new-news)
    (setq rra-last-mail-low-check (float-time))
    (setq rra-last-mail-normal-check (float-time))
    (setq rra-last-mail-important-check (float-time)))
   ((> (float-time) (+ rra-last-mail-normal-check
                       rra-mail-normal-check-interval))
    (gnus-group-get-new-news 3)
    (setq rra-last-mail-normal-check (float-time))
    (setq rra-last-mail-important-check (float-time)))
   ((> (float-time) (+ rra-last-mail-important-check
                       rra-mail-important-check-interval))
    (gnus-group-get-new-news 1)
    (setq rra-last-mail-important-check (float-time)))
   (t
    (let ((next-check (+ rra-last-mail-important-check
                         rra-mail-important-check-interval)))
      (message (concat "No gnus is good news ("
                       (int-to-string (floor (- next-check (float-time))))
                       " seconds until check allowed)"))))))

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: Restricting frequency of 'g'

[Ted Zlatanov]

On Thu, 07 Oct 2010 14:55:07 -0700 Russ Allbery <rra@stanford.edu> wrote: 

RA> I absolutely swear by my implementation, although I wouldn't use the one
RA> that you're responding to.  It's a really valuable tool in helping me
RA> avoid the temptation to spend all day checking my mail.

FWIW I've solved this by using graphics (SVG icons) instead of numbers.
With my implementation, I can't tell a difference of 1% but can
definitely tell 20% or more.

Ted

Re: Restricting frequency of 'g'

[Jason L Tibbitts III]

>>>>> "LMI" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

LMI> The functionality doesn't seem all that compelling...  Would many
LMI> people use it?

Actually I've been looking for something like that for quite some time.
For most of my reading, there's really no point in bothering to visit a
high-traffic group until it has a quantity of articles in it.

Of course, I could solve that problem with discipline, but it's far more
fun to solve it with software.

 - J<

Re: Restricting frequency of 'g'

[Lars Magne Ingebrigtsen]

"Jason L Tibbitts III" <tibbs@math.uh.edu> writes:

> Actually I've been looking for something like that for quite some time.
> For most of my reading, there's really no point in bothering to visit a
> high-traffic group until it has a quantity of articles in it.

Yes, I can see attraction of something like that.  Russ' implementation
is based on scanning frequency, while the Mark Plaksin's is based more
on the number of articles in the group, and Ted's is based on not
showing the details of how many articles there are unread.

So we seem to have at least three different approaches to the same
idea.  It could be that this is the sort of thing that's difficult to
provide, but requires that people just write their own variations to fit
their own needs.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Restricting frequency of 'g'

[Richard Riley]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> "Jason L Tibbitts III" <tibbs@math.uh.edu> writes:
>
>> Actually I've been looking for something like that for quite some time.
>> For most of my reading, there's really no point in bothering to visit a
>> high-traffic group until it has a quantity of articles in it.
>
> Yes, I can see attraction of something like that.  Russ' implementation
> is based on scanning frequency, while the Mark Plaksin's is based more
> on the number of articles in the group, and Ted's is based on not
> showing the details of how many articles there are unread.
>
> So we seem to have at least three different approaches to the same
> idea.  It could be that this is the sort of thing that's difficult to
> provide, but requires that people just write their own variations to fit
> their own needs.

Hmm. Interesting take. With three different versions already in
existence it would suggest its not that difficult to provide, but more
difficult to choose a "best fit" solution.