Re: [PATCH] generic spam detection
* On 2004.07.12, in <20040712142005.GA44582@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
* "TAKAHASHI Tamotsu" <ttakah@xxxxxxxxxxxxxxxxx> wrote:
>
> Just now, I am trying your patch.
Thanks for your comments.
> I think it is a very great enhancement. (%1-substitution, in particular.)
> It is not only for spam, but also for extremely flexible index_formatting.
> We can (ab)use this feature to show the summary of a message's header
> information, for example.
True -- I hadn't thought of that. :)
> I am using hcache.18 patch. Your spam detection ignores cached messages.
> i.e. This doesn't work with hcache patch at all.
> ...
> 2. If one or two of the patches (hcache.19 and hormel.2) are included
> into CVS, this problem will be fixed soon (by sithglan or dgc, hehehe).
> (upstream side; The best solution!!!)
There are several header-caching patches available now. The problem
occurs because the caching patches circumvent the usual ways of loading
message HEADERs and ENVELOPEs, so each patch would require its own
update. Since Thomas has said that the hormel patch looks right for CVS,
I'm going to take the easy way out and leave it to those patch authors
to update for future releases -- sorry, but this seems like the least
trouble/effort expended for all, in that it provides one stable base for
others to work against.
> BTW, I suggest you set a default value of $spam_separator.
> Maybe ", " or "/".
> With a default value, all we have to do is execute "spam" command
> as many times as we need. Very simple usage. Good for beginners.
I saw your followup saying to ignore this. I just want to remark that
this is reasonable, but a style decision. I favored simplicity over
complexity to make things easier for new users, but it certainly could
be done differently, and there's a beginning-user argument for showing
them all by default, too. I don't have much opinion on this.
> One more suggestion; Redraw display more often.
> Your patch defines spam_separator with "R_NONE."
> I guess "R_INDEX" is better. (I haven't tested yet.)
This is probably appropriate, but perhaps should be
R_INDEX|R_RESORT_BOTH since it affects index collation as well.
> Lastly, I want "unspam" and "unnospam" to remove spam definitions.
> I often misspell regexps and I have to remove such entries from list.
I was hoping to avoid this -- it didn't really seem all that useful.
My reasoning has been that in general, a user will experiment a little
and find some spam/nospam settings that work, then continue using
exactly those settings for months, without ever entering new ones
interactively. That is, there won't often be a need to undo, and in the
initial stages where there is, it's not so bad to quit & restart.
But I can see a need for this if spam/nospam are used for more than just
spam. Does anyone else have thoughts on this?
--
-D. dgc@xxxxxxxxxxxx NSIT::ENSS
No money, no book. No book, no study. No study, no pass.
No pass, no graduate. No graduate, no job. No job, no money.
T h e U n i v e r s i t y o f C h i c a g o