Pre-Processed maiil splitting under Gnus?

Pre-Processed maiil splitting under Gnus?

[Asymptotically Approaching Relaxation]

Hi folks, I'm at somewhat of an impass.

I love Gnus.  However I'm running it on a Cyrix 686 150 with 64 Megs na
RAM and even so watching Gnus split and filter my incoming mail is
_so_mind_blisteringly_slow_ that I simply can't cope anymore :)

(Note: I'm NOT slamming Gnus here.  It's elisp, and given the number of
 sexpr's it has to eval per message filtered I think it does a *fine*
 job.  It's just that every time I go to read my mail, it gets more and
 more painful every day to spend 5+ minutes watching Gnus go *chuggachugga*)

So.. Is there a away, maybe with XEmacs in batch mode or whatever, to have
some sort of daemonized Gnus process pre-filter my mail so that when I log
in it'll be all split as it should be?

I looked at using procmail, but the procmail/nnfolder solution seems complex
and I want to make sure I'm not missing something before I go convert my
1.5 pages of nnmail-split-methods into procmail syntax.

Thanks!

-Chris P.

Re: Pre-Processed maiil splitting under Gnus?

[Richard Coleman]

> I love Gnus.  However I'm running it on a Cyrix 686 150 with 64 Megs na
> RAM and even so watching Gnus split and filter my incoming mail is
> _so_mind_blisteringly_slow_ that I simply can't cope anymore :)
> 
> (Note: I'm NOT slamming Gnus here.  It's elisp, and given the number of
>  sexpr's it has to eval per message filtered I think it does a *fine*
>  job.  It's just that every time I go to read my mail, it gets more and
>  more painful every day to spend 5+ minutes watching Gnus go *chuggachugga*)
> 
> So.. Is there a away, maybe with XEmacs in batch mode or whatever, to have
> some sort of daemonized Gnus process pre-filter my mail so that when I log
> in it'll be all split as it should be?
> 
> I looked at using procmail, but the procmail/nnfolder solution seems complex
> and I want to make sure I'm not missing something before I go convert my
> 1.5 pages of nnmail-split-methods into procmail syntax.

I don't think the procmail solution is very complicated.  Don't use
procmail to save directly to a nnfolder file.  Instead, have it save
your messages into multiple (pre-filtered) spool files, which Gnus will
incorporate directly into the correct group.  There is an entry in the
Gnus FAQ that shows exactly how to set this up.  It's pretty easy (from
the perspective of Gnus).  That is assuming you know how to use
procmail (which is not that hard).

--
Richard Coleman
coleman@math.gatech.edu

Re: Pre-Processed maiil splitting under Gnus?

[Asymptotically Approaching Relaxation]

Richard Coleman <coleman@math.gatech.edu> writes:

> > I love Gnus.  However I'm running it on a Cyrix 686 150 with 64 Megs na
> > RAM and even so watching Gnus split and filter my incoming mail is
> > _so_mind_blisteringly_slow_ that I simply can't cope anymore :)
> > 
> > (Note: I'm NOT slamming Gnus here.  It's elisp, and given the number of
> >  sexpr's it has to eval per message filtered I think it does a *fine*
> >  job.  It's just that every time I go to read my mail, it gets more and
> >  more painful every day to spend 5+ minutes watching Gnus go *chuggachugga*)
> > 
> > So.. Is there a away, maybe with XEmacs in batch mode or whatever, to have
> > some sort of daemonized Gnus process pre-filter my mail so that when I log
> > in it'll be all split as it should be?
> > 
> > I looked at using procmail, but the procmail/nnfolder solution seems complex
> > and I want to make sure I'm not missing something before I go convert my
> > 1.5 pages of nnmail-split-methods into procmail syntax.
> 
> I don't think the procmail solution is very complicated.  Don't use
> procmail to save directly to a nnfolder file.  Instead, have it save
> your messages into multiple (pre-filtered) spool files, which Gnus will
> incorporate directly into the correct group.  There is an entry in the
> Gnus FAQ that shows exactly how to set this up.  It's pretty easy (from
> the perspective of Gnus).  That is assuming you know how to use
> procmail (which is not that hard).

Well, yes that's a good point, and thanks for making it, but my issue
was that I'm trying to *AVOID* the procmail route.

As ratinox pointed out, the splitting process on my system is *WAY TOO 
SLOW* maybe there's something I'm doing somewhere, I dunno..

-Chris
____________________________________________________________________
|Chris Patti|ICQ#16333120|feoh@cosmic.com|Home #:(617)625-3194|JAPH|
|"I have opposable thumbs, and I can buy a rifle.  I don't need to |
| run from anything." -Todd Finney				   |

using multiple Summary buffer formats

[Alfred J Correira]

I've been poking around in the documentation on the Summary buffer for a way to
do the following, but I just don't see how to do it simply.  Namely, I would
like to have one Summary buffer format for all my groups, except my outgoing
group (the GCC: group); I would like that one to use a format that displayed,
say, the first To: address rather than the usual From: (they're all from me,
after all :-).  It looks like perhaps I could make up my own function to bind
to the gnus-extract-address-components variable, one that checks for my GCC
group and does something different than the usual predefined functions when I'm
in that group, but that feels wrong to me somehow.  Am I missing some obvious
existing mechanism that supports what I want to do?

(This would for pgnus v0.69 ...)

-- 
Work: Alfred.Correira@GlobeSet.Com  PH: 512.427.7715
Home: Correira@Flash.Net           FAX: 512.427.5101
PGP: 55 42 BB 2E 17 E9 0D 9C 0B 51 66 58 58 96 1E 45

Re: using multiple Summary buffer formats

[Kai.Grossjohann]

alfred@GlobeSet.com (Alfred J Correira) writes:

  > I've been poking around in the documentation on the Summary buffer
  > for a way to do the following, but I just don't see how to do it
  > simply.  Namely, I would like to have one Summary buffer format
  > for all my groups, except my outgoing group (the GCC: group); I
  > would like that one to use a format that displayed, say, the first
  > To: address rather than the usual From: (they're all from me,
  > after all :-).

It is simple to display the To header for all messages from you.  It
works like this:

First, you tell Gnus to save extra headers in the overview files, and
to make use of it:

(setq gnus-extra-headers '(To))
(setq nnmail-extra-headers gnus-extra-headers)

To actually put the new headers in the old overview files, type M-x
nnml-generate-nov-databases RET.

To tell Gnus to display the new headers, substitute %n in
gnus-summary-line-format with %f.

kai
-- 
Abort this operation?   [Abort]  [Cancel]

Re: using multiple Summary buffer formats

[Lee Willis]

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:

> It is simple to display the To header for all messages from you.  It
> works like this:
> 
[Snipped v.good description]

This all works beautifully except for one thing. I'd like to have this
on for some groups and off or others. ie. I like to see the To: line
displayed in my archive groups which contain most of my sent
mail. However I have some groups that I GCC: into directly so that I
have all my conversations with one person in one folder, and in these
I'd like to see the From address ie the old behaviour. 

As an example

O  -> mikeb@gbdirect.co.uk  Re: Gotta have this logo
O  -> scoll_methods  FAO: J.Creasey Re: Inserting course data
O  -> Russell Smith  Re: Hi -de - hi

is great in my archive files but

O  Jane Gillis  (none)
O      -> Jane Gillis  Re: none
OA Jane Gillis  (none)
O      -> Jane Gillis  Re: none

seems less intuitive than

O  Jane Gillis  (none)
O      Lee Willis  Re: none
OA Jane Gillis  (none)
O      Lee Willis  Re: none

in one of my per person groups. Is there an easy way to do this or would
it require writing a hook, which I think I can probably do with some
trial and error if that's the way to go, I was just wondering if there
was an easier way,

Lee.
-- 
I was doing object-oriented assembly at 1 year old ...  
For some reason my mom insists on calling it "Playing with blocks"

Re: using multiple Summary buffer formats

[Kai.Grossjohann]

Lee Willis <lee@gbdirect.co.uk> writes:

  > in one of my per person groups. Is there an easy way to do this or would
  > it require writing a hook, which I think I can probably do with some
  > trial and error if that's the way to go, I was just wondering if there
  > was an easier way,

The following creates a different format for the nnml:mail.misc and
nnml:outgoing groups.  I'm sure you see how to do this for other
groups.

Untested!

(defun my-frob-gnus-summary-line-format ()
  (make-local-variable 'gnus-summary-line-format)
  (if (string-match "nnml:mail.misc\\|nnml:outgoing"
                    gnus-newsgroup-name)
      (setq gnus-summary-line-format "..value with %f..")
    (setq gnus-summary-line-format "..value with %n..")))

(add-hook 'gnus-summary-generate-hook 'my-frob-gnus-summary-line-format)

Maybe you need a different gnus-summary-*-hook variable.

kai
-- 
Abort this operation?   [Abort]  [Cancel]

Re: using multiple Summary buffer formats

[Kai.Grossjohann]

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:

  > But from the name, it seems that *-prepare-hook is the right place.
  > Hm.  If that doesn't work, ask Lars.

Arg!  I forgot gnus-ignored-from-addresses.  You must set
gnus-ignored-from-addresses.

Sorry.  Does it work now?

kai
-- 
Abort this operation?   [Abort]  [Cancel]

Re: using multiple Summary buffer formats

[Lee Willis]

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE writes:
> 
>   > But from the name, it seems that *-prepare-hook is the right place.
>   > Hm.  If that doesn't work, ask Lars.
> 
> Arg!  I forgot gnus-ignored-from-addresses.  You must set
> gnus-ignored-from-addresses.

Yep, I've done that. It's recognizing me fine, and displaying to To:
address in every folder for mails sent by me. The problem is that I
can't get it to show the From address in some groups. The code you sent
seems to be working in that it sets a local copy of
gnus-summary-line-format correctly, but this value doesn't seem to be
used when creating the summary. It uses the global one instead.

Lars?

Lee.
-- 
I was doing object-oriented assembly at 1 year old ...  
For some reason my mom insists on calling it "Playing with blocks"

Re: using multiple Summary buffer formats

[Karl Kleinpaste]

I suggest use of gnus-group-select-hook instead.  This is mine:

(setq gnus-select-group-hook
      (function
       (lambda ()
	 ;; Ignore From: in summary for certain groups.
	 (cond ((string-match "clari." gnus-newsgroup-name)
		(setq gnus-summary-line-format
		      "%U%R%z%I%(%[%4L: %-6,6n%]%)   %s\n"))
	       ((string-match "comp.sources" gnus-newsgroup-name)
		(setq gnus-summary-line-format
		      "%U%R%z%I%(%[%4L%]%)   %s\n"))
	       (t
		(setq gnus-summary-line-format
		      "%U%R%z%I%(%[%4L: %-20,20f%]%) %s\n")))
	 ;; Put full newsgroup name in summary mode line for nnir.
	 (setq gnus-summary-mode-line-format
	       (if (string-match "nnir:" gnus-newsgroup-name)
		   "Gnus: %G [%A] %Z" "Gnus: %g [%A] %Z"))
	 ;; Convince certain mailing lists that their trailers are Bad.
	 (if (string-match "list.\\(guns\\|pa-pol\\|pabdsm\\|leatherparent\\|trpn\\|y2kprep\\)" gnus-newsgroup-name)
	     (add-hook 'gnus-article-display-hook 'gnus-article-hide-signature t)
	   (remove-hook 'gnus-article-display-hook 'gnus-article-hide-signature))
	 ))

Re: using multiple Summary buffer formats

[Jack Vinson]

>>>>> "KK" == Karl Kleinpaste <karl@justresearch.com> writes:

KK> I suggest use of gnus-group-select-hook instead.  This is mine:

Another option is to create your own format-function to handle this.  Since
I use BBDB to extract user names for mail, the tricks to show the To:
information in some groups is more difficult.  

This is what my setup looks like.  Instead of %-20,20f, I have %-20,20ud to
indicate use of the gnus-user-format-function-d.  The function simply
checks the group name and does either gnus-summary-from-or-to-or-newsgroups
(the %f behavior) or bbdb/gnus-summary-get-author (the %uB behavior).

(setq  gnus-summary-line-format "%U%R%z%I%(%[%4L: %-20,20ud%]%) %s\n")
(defun gnus-user-format-function-d (group-tmp)
  "Decide to use either the BBDB function or the %f form."
  (let ((group gnus-newsgroup-name))
    ;; Set the Summary Line Format special for outgoing archives
    (if (and group
	     (string-match "\\(drafts\\|misc-\\(mail\\|news\\)\\)" group))
	;; gnus-tmp-header is defined in the calling function
	(gnus-summary-from-or-to-or-newsgroups group-tmp)
      (bbdb/gnus-summary-get-author group-tmp)
    ))
  )

-- 
Jack Vinson <jvinson@chevax.ecs.umass.edu>    http://www.cis.upenn.edu/~vinson/
Zippy: Did you GAIN WEIGHT in th' past 5 MINUTES or am I just DREAMING of two
 BROCCOLI FLORETS lying in an empty GAS TANK?

Re: using multiple Summary buffer formats

[Lee Willis]

Jack Vinson <jvinson@chevax.ecs.umass.edu> writes:

> >>>>> "KK" == Karl Kleinpaste <karl@justresearch.com> writes:
> 
> Another option is to create your own format-function to handle this. 

[Snipped code]

Which works brilliantly, except I'd prefer it to show the From line
rather than the BBDB entry, but for the moment it's working very
nicely. Thanks a lot Jack.

Lee.
-- 
I was doing object-oriented assembly at 1 year old ...  
For some reason my mom insists on calling it "Playing with blocks"

Re: Pre-Processed maiil splitting under Gnus?

[Asymptotically Approaching Relaxation]

Stainless Steel Rat <ratinox@peorth.gweep.net> writes:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> "AAR" == Asymptotically Approaching Relaxation <feoh@cosmic.com> writes:
> 
> AAR> (Note: I'm NOT slamming Gnus here.  It's elisp, and given the number
> AAR> of sexpr's it has to eval per message filtered I think it does a
> AAR> *fine* job.  It's just that every time I go to read my mail, it gets
> AAR> more and more painful every day to spend 5+ minutes watching Gnus go
> AAR> *chuggachugga*)
> 
> 5 *MINUTES*?  Gnus and FSF Emacs 19.34 on old 486 DX2-50 with 12Mb RAM,
> running Windows 95, would split a 250-message mail spool file in under 30
> seconds.  This was using nnml, the slowest-writing backend available to
> Gnus, on a VFAT filesystem, one of the slowest filesystems available on any
> OS running on the Intel architecture.
> 
> I think there is something seriously wrong with your system, not Gnus.

To answer my own question:

I'm seeing a total performance turnaround once I re-wrote my .gnus
file and minimized the length and complexity of the regexes I'm
filtering on.

I'd written the thing in the early days before I got used to how emacs 
groks regexes, and was being *extremely* paranoid about full
hostnames, etc.

-Chris
____________________________________________________________________
|Chris Patti|ICQ#16333120|feoh@cosmic.com|Home #:(617)625-3194|JAPH|
|"I have opposable thumbs, and I can buy a rifle.  I don't need to |
| run from anything." -Todd Finney				   |

Re: Pre-Processed maiil splitting under Gnus?

[Kai.Grossjohann]

Asymptotically Approaching Relaxation <feoh@cosmic.com> writes:

  > I'm seeing a total performance turnaround once I re-wrote my .gnus
  > file and minimized the length and complexity of the regexes I'm
  > filtering on.

Ah.  Why didn't I think of this?  Since the Day of the Posixification
of Regexes, regex matching has been rather slower for a number of
regexes; and I'm not sure whether the fact that they're posixly
correct now should be considered a Good Thing...

kai
-- 
Just because I'm paranoid doesn't mean they're not out there to get me!

Re: Pre-Processed maiil splitting under Gnus?

[Hrvoje Niksic]

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:

> Asymptotically Approaching Relaxation <feoh@cosmic.com> writes:
> 
>   > I'm seeing a total performance turnaround once I re-wrote my .gnus
>   > file and minimized the length and complexity of the regexes I'm
>   > filtering on.
> 
> Ah.  Why didn't I think of this?  Since the Day of the
> Posixification of Regexes, regex matching has been rather slower for
> a number of regexes; and I'm not sure whether the fact that they're
> posixly correct now should be considered a Good Thing...

Strange.  Two remarks, though (none of which is meant to argue with
you):

1) As demonstrated by Tom Lord, GNU regex (which both Emacsen use) is
   still not POSIX.

2) Why are there, at least in XEmacs, two sets of functions, posix-
   regexp functions, and "normal" regexp functions?  Also, the
   internal code has various posix-p flags that apparently specify
   whether POSIX behaviour is desired.  I though the reason for
   duplicate functionality was to gain speed in the non-POSIX (the
   more usual) case.

M-x gnus-filter-mail-at-warp-10 (was: Re: Pre-Processed maiil splitting under Gnus?)

[Asymptotically Approaching Relaxation]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE writes:
> 
> > Asymptotically Approaching Relaxation <feoh@cosmic.com> writes:
> > 
> >   > I'm seeing a total performance turnaround once I re-wrote my .gnus
> >   > file and minimized the length and complexity of the regexes I'm
> >   > filtering on.
> > 
> > Ah.  Why didn't I think of this?  Since the Day of the
> > Posixification of Regexes, regex matching has been rather slower for
> > a number of regexes; and I'm not sure whether the fact that they're
> > posixly correct now should be considered a Good Thing...
> 
> Strange.  Two remarks, though (none of which is meant to argue with
> you):
> 
> 1) As demonstrated by Tom Lord, GNU regex (which both Emacsen use) is
>    still not POSIX.
> 
> 2) Why are there, at least in XEmacs, two sets of functions, posix-
>    regexp functions, and "normal" regexp functions?  Also, the
>    internal code has various posix-p flags that apparently specify
>    whether POSIX behaviour is desired.  I though the reason for
>    duplicate functionality was to gain speed in the non-POSIX (the
>    more usual) case.


Hrrm.  I'm not sure whether or not XEmacs' regexps Posixness or lack
thereof is the determining faactor here.  I suspect a dash of clue and 
a *MUCH* less complex string to parse per each filter are the cause.

Here's the first bits of my nnmail-split-methods, old and new:

OLD: <Note: There are several syntactically legal but obviously broken
      expressions here, this didn't help in any case :)>

(setq nnmail-split-methods
	'(("mail.imagine" ".*owner-imagine@MAELSTROM\.STJOHNS\.EDU")
	("mail.mesa" "Return-Path:.*mesa.*.BR.*")
	("mail.kaffe" "Sender:.*kaffe@w3\.org")
	("mail.0xdeadbeef" ".*0xdeadbeef@substance\.abuse\.blackdown\.org")
	("mail.0xdeadbeef" "To:.*0xdeadbeef@substance.abuse.blackdown.org")
	("mail.linux-kernel" "linux-kernel@vger\.rutgers\.edu")
	("mail.linux-smp" "linux-smp@vger\.rutgers\.edu")
	("mail.linux-net" "linux-net@vger\.rutgers\.edu")
	("mail.linux-gcc" "linux-gcc@vger\.rutgers\.edu")
	("mail.linux-svgalib" "linux-svgalib@vger\.rutgers\.edu")
	("mail.linux-tape" "linux-tape@vger\.rutgers\.edu")
	("mail.linux-scsi" "linux-scsi@vger\.rutgers\.edu")

...


NEW: 
(setq nnmail-split-methods
	("mail.imagine" "owner-imagine@")
	("mail.0xdeadbeef" "0xdeadbeef@")
	("mail.gnus" "ding@gnus\.org")
	("mail.gimp" "gimp-.+@")
	("mail.hwg-languages" "hwg-languages@")
	("mail.hwg-critique" "hwg-critique@")
	("mail.hwg-software" "hwg-software@")
	("mail.squeak" "squeak@cs\.uiuc\.edu")
	("mail.boston-pm" "boston-pm@")
	("mail.perldl" "perldl@")
	("mail.freshmeat" "freshmeat-news@")

...

You get the idea.

To at least somewhat quantify my performance boost, a mail spool of
approx. 100 messages used to take on the order of a minute plus some
slop.  The same spool now filters in a little under 3 seconds :)

Yay.  I don't have to mess with procmail :)

-Chris
(I personally still favor pre versus post processing, but the pain is
gone so I'll move on to the next egregious wound and call it a win :)
____________________________________________________________________
|Chris Patti|ICQ#16333120|feoh@cosmic.com|Home #:(617)625-3194|JAPH|
|"I have opposable thumbs, and I can buy a rifle.  I don't need to |
| run from anything." -Todd Finney				   |

Re: M-x gnus-filter-mail-at-warp-10 (was: Re: Pre-Processed maiil splitting under Gnus?)

[Kai.Grossjohann]

Asymptotically Approaching Relaxation <feoh@cosmic.com> writes:

  > (setq nnmail-split-methods
  > 	'(("mail.imagine" ".*owner-imagine@MAELSTROM\.STJOHNS\.EDU")
  > 	("mail.mesa" "Return-Path:.*mesa.*.BR.*")
  > 	("mail.kaffe" "Sender:.*kaffe@w3\.org")
  > 	("mail.0xdeadbeef" ".*0xdeadbeef@substance\.abuse\.blackdown\.org")
  > 	("mail.0xdeadbeef" "To:.*0xdeadbeef@substance.abuse.blackdown.org")
  > 	("mail.linux-kernel" "linux-kernel@vger\.rutgers\.edu")
  > 	("mail.linux-smp" "linux-smp@vger\.rutgers\.edu")
  > 	("mail.linux-net" "linux-net@vger\.rutgers\.edu")
  > 	("mail.linux-gcc" "linux-gcc@vger\.rutgers\.edu")
  > 	("mail.linux-svgalib" "linux-svgalib@vger\.rutgers\.edu")
  > 	("mail.linux-tape" "linux-tape@vger\.rutgers\.edu")
  > 	("mail.linux-scsi" "linux-scsi@vger\.rutgers\.edu")

I'm sure that these can be made faster by always using the header name
(a number of these don't have headers), and by prefixing the header
name with "^" (which means at beginning of line).

To be specific: the "mail.kaffe" regex could be
"^Sender:.*kaffe@w3.org".

Also, note that the Lisp reader expands "\." to "." so "foo\.bar" and
"foo.bar" are the same.  If you want to match a dot, use "\\.".

kai
-- 
Just because I'm paranoid doesn't mean they're not out there to get me!

Re: M-x gnus-filter-mail-at-warp-10 (was: Re: Pre-Processed maiil splitting under Gnus?)

[Asymptotically Approaching Relaxation]

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:

> Asymptotically Approaching Relaxation <feoh@cosmic.com> writes:
> 
>   > (setq nnmail-split-methods
>   > 	'(("mail.imagine" ".*owner-imagine@MAELSTROM\.STJOHNS\.EDU")
>   > 	("mail.mesa" "Return-Path:.*mesa.*.BR.*")
>   > 	("mail.kaffe" "Sender:.*kaffe@w3\.org")
>   > 	("mail.0xdeadbeef" ".*0xdeadbeef@substance\.abuse\.blackdown\.org")
>   > 	("mail.0xdeadbeef" "To:.*0xdeadbeef@substance.abuse.blackdown.org")
>   > 	("mail.linux-kernel" "linux-kernel@vger\.rutgers\.edu")
>   > 	("mail.linux-smp" "linux-smp@vger\.rutgers\.edu")
>   > 	("mail.linux-net" "linux-net@vger\.rutgers\.edu")
>   > 	("mail.linux-gcc" "linux-gcc@vger\.rutgers\.edu")
>   > 	("mail.linux-svgalib" "linux-svgalib@vger\.rutgers\.edu")
>   > 	("mail.linux-tape" "linux-tape@vger\.rutgers\.edu")
>   > 	("mail.linux-scsi" "linux-scsi@vger\.rutgers\.edu")
> 
> I'm sure that these can be made faster by always using the header name
> (a number of these don't have headers), and by prefixing the header
> name with "^" (which means at beginning of line).
> 
> To be specific: the "mail.kaffe" regex could be
> "^Sender:.*kaffe@w3.org".
> 
> Also, note that the Lisp reader expands "\." to "." so "foo\.bar" and
> "foo.bar" are the same.  If you want to match a dot, use "\\.".
> 
> kai

I did that in the New: section, dunno if you caught that :)

Thanks for pointing out the thing about \. versus \\. though.

Clearly I need to go bash my head against the emacs-isms I'm not
getting.

Oh for a single regexp standard :)

I say we declare "Perl" and be done with it. <duck>

-Chris
____________________________________________________________________
|Chris Patti|ICQ#16333120|feoh@cosmic.com|Home #:(617)625-3194|JAPH|
|"I have opposable thumbs, and I can buy a rifle.  I don't need to |
| run from anything." -Todd Finney				   |

Re: M-x gnus-filter-mail-at-warp-10 (was: Re: Pre-Processed maiil splitting under Gnus?)

[Kai.Grossjohann]

Asymptotically Approaching Relaxation <feoh@cosmic.com> writes:

  > I did that in the New: section, dunno if you caught that :)

Hm?  I suggested using "^" and "\\.", neither were used in the `new'
section (nor in the `old' section, for that matter).  I suggested an
additional possibility for making it faster (though I haven't actually
tested it, so it's just a stab in the dark).

You did make it faster in the `new' section, though :-) but by other
means.

kai
-- 
Just because I'm paranoid doesn't mean they're not out there to get me!

Re: M-x gnus-filter-mail-at-warp-10 (was: maiil splitting under Gnus?)

[Jari Aalto+mail.procmail]

*  1999-01-12 Asymptotically Approaching Relaxation <feoh@cosmic.com>
| To at least somewhat quantify my performance boost, a mail spool of
| approx. 100 messages used to take on the order of a minute plus some
| slop.  The same spool now filters in a little under 3 seconds :)

The Gnus and Procmail are two diffrent methods. The Prcmail is always there
and filtering the mail, whereas you have to keep Gnus running or
active to have mail split.

If I take a vacation or Gnus(Emacs) process dies, the procmail still cruches
the messages to right folders. In addition reading the groups with
new mail take no time at all :-)

All of your Maling lists could have been trapped with simple procmail module
call:

    # ~/.procmailrc start

    PMSRC = $HOME/.procmail             # procmail module source directory
    SPOOL = $HOME/Mail/spool            # The Gnus procmail spool

    INCLUDERC = $PMSRC/pm-jalist.rc     # see if this the mailing list message

    #   if this was mailing list, drop to mailing list folder. The mailing
    #   list name is already derived to LIST
    #
    #   linux-announce --> $HOME/Mail/spool/list.linux-announce.spool
    
    :0 :                
    * LIST ?? [a-z]
    $SPOOL/list.$LIST.spool

    # end ~/.procmailrc

This same recipe adaptively finds any new mailing list you may subsribe to.

jari

Re: M-x gnus-filter-mail-at-warp-10 (was: maiil splitting under Gnus?)

[Kai.Grossjohann]

jari.aalto@poboxes.com (Jari Aalto+mail.procmail) writes:

  > The Gnus and Procmail are two diffrent methods. The Prcmail is
  > always there and filtering the mail, whereas you have to keep Gnus
  > running or active to have mail split.

Mail is split when Gnus starts.  Is that not sufficient?

Except for the possible problem of the regex matching thingy taking
quite some time when done all in one go.  I agree that this might be
an issue for some people.

kai
-- 
Just because I'm paranoid doesn't mean they're not out there to get me!

Re: M-x gnus-filter-mail-at-warp-10 (was: maiil splitting under Gnus?)

[Hrvoje Niksic]

Kai.Grossjohann@CS.Uni-Dortmund.DE writes:

> jari.aalto@poboxes.com (Jari Aalto+mail.procmail) writes:
> 
>   > The Gnus and Procmail are two diffrent methods. The Prcmail is
>   > always there and filtering the mail, whereas you have to keep Gnus
>   > running or active to have mail split.
> 
> Mail is split when Gnus starts.  Is that not sufficient?

It's not, if you want things getting done when mail arrives, as is
usually done with mail robots or vacation programs.  In Both Gnus and
procmail, you can execute code when (certain types of) mail arrives.
Obviously, procmail is much better suited for tasks of that kind.

For this reason, I use two layers of mail filtering; one
procmail-based, for the stuff that needs to get done as soon as the
mail arrives, and one Gnus-based for normal mailing-list splitting.

Re: Pre-Processed maiil splitting under Gnus?

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> 1) As demonstrated by Tom Lord, GNU regex (which both Emacsen use) is
>    still not POSIX.
> 
> 2) Why are there, at least in XEmacs, two sets of functions, posix-
>    regexp functions, and "normal" regexp functions?  Also, the
>    internal code has various posix-p flags that apparently specify
>    whether POSIX behaviour is desired.  I though the reason for
>    duplicate functionality was to gain speed in the non-POSIX (the
>    more usual) case.

My understanding of this is that certain Posixly things were
incorporated -- in specific, a more complex backtracking thing.
Backtracking can be very slow, so the non-Posix functions use a
simpler version.  So the naming is misleading -- it should probably be 
excessive-backtracking-p instead of posix-p, but the latter rolls more 
easily off the tongue, perhaps.

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