backgrounded expire deletes

backgrounded expire deletes

[Wesley.Hardaker]

I've thought for a long time, as I watch my stupid screen saying
'deleting article XXX...' for a long time that it would really cool to
have all the deletions done at either a later point or in the
background.  There are two possible solutions as I see it:

1) put the file name in a buffer and save the buffer on exiting gnus,
   and allow a cron job to check for the file at night and remove the
   articles then.

2) collect names of the files and pass them to a long winded /bin/rm
   system call with a '&' at the end.

I suspect that gnus will get confused if you do #1 and then re-enter
gnus before the cron job hits it?

Wes

Re: backgrounded expire deletes

[Kai Grossjohann]

>>>>> Wesley Hardaker writes:

  Wes> I've thought for a long time, as I watch my stupid screen
  Wes> saying 'deleting article XXX...' for a long time that it would
  Wes> really cool to have all the deletions done at either a later
  Wes> point or in the background.

Seems like these come from the expiry process.  Here's what I use:

(remove-hook 'gnus-summary-prepare-exit-hook 'gnus-summary-expire-articles)

I have bound a convenient key in the *Group* buffer to
gnus-group-expire-all-groups.  I hit this key every day before I go to
lunch.

Would that be a sloution?

kai
-- 
Life is hard and then you die.

Re: backgrounded expire deletes

[Ken Raeburn]

I've been thinking about this recently too.

> 1) put the file name in a buffer and save the buffer on exiting gnus,
>    and allow a cron job to check for the file at night and remove the
>    articles then.
> 
> 2) collect names of the files and pass them to a long winded /bin/rm
>    system call with a '&' at the end.

Both of these still require spending a lot of time stat'ing each file
when exiting the group.  They probably would cut the time about in
half.  (The stat info can be cached, but in the current implementation
a lot more stats are done than necessary when you have sparse article
numbers.)

How about adding the group to a list of groups that should be expired,
maybe with a list of article numbers to check, and doing the
expiration while idle?  A function could be fired up when emacs is
idle for 5 seconds or do.  It could check and maybe delete a couple of
articles, check for input availability using sit-for, and continue if
none is available or reschedule itself if it is.

If you enter a group already on the list, just remove it from the
list; it'll get re-added when you leave.

On exiting gnus, perhaps the remaining expirations could be run, or
the state could be saved away in .newsrc.eld for processing next time
gnus is fired up.

This could leave unsaved .overview buffers around some of the time
while the expires are in progress.  I'm not sure if that'd be a big
problem, or how best to deal with it if it is.  Maybe they could be
saved when available input is detected.  This would cost a bit of
efficiency, but overall we'd probably win by avoiding large delays for
the user.

Re: backgrounded expire deletes

[Colin Rafferty]

>>>>>> "Kai" == Kai Grossjohann <grossjohann@charly.informatik.uni-dortmund.de> writes:
>>>>>> "Wes" == Wesley Hardaker writes:

Wes> I've thought for a long time, as I watch my stupid screen
Wes> saying 'deleting article XXX...' for a long time that it would
Wes> really cool to have all the deletions done at either a later
Wes> point or in the background.

Kai> Seems like these come from the expiry process.  Here's what I use:

Kai> (remove-hook 'gnus-summary-prepare-exit-hook 'gnus-summary-expire-articles)

Kai> I have bound a convenient key in the *Group* buffer to
Kai> gnus-group-expire-all-groups.  I hit this key every day before I go to
Kai> lunch.

"C-c C-M-x runs the command gnus-group-expire-all-groups"

Kai> Would that be a sloution?

I think this is the simplest solution.  This is what I use.

-- 
Colin