SciFi posted on Wed, 30 Jul 2014 20:32:58 +0000 as excerpted: > Request #1. — Alter the logic for Score/Flag filter rules to ignore the > "alphabet soup". > > We need to be able to specify a Regex type filter for the Subject line. > I know there's an option on the main Pan panel for Articles → Add a > Scoring Rule… → Subject → matches regex → [fill it in here]. But does > it work as the attached post for Forte Agent works?
[This reply is basically a high-detail confirmation of Andreas' reply. If you want the simple version, read his reply and skip the rest of this one.] FWIW, pan's (slrn's) scorefile format is in fact native regex for the header-field lines, so editing the scorefile directly for that should work just fine and indeed, using the regex choice in the GUI should be fine as well, tho if you experience problems with it or for the more advanced stuff, it's always useful to be able to know how to directly edit the scorefile itself. Pan's scoring GUI is primarily an attempt to simplify things, including allowing users who don't know regex access to at least the simplest and most common "straight text plus beginning and ending anchors" matching functionality of regex, and what pan puts in the scorefile is actually regex even for the other GUI options. One useful exception to know about is the negation character, "~", that can prepend any keyword line (not the regex found after the keyword). Also very useful is knowing that lines starting with % are comments. In fact, most of the lines pan adds are actually comments and can be deleted or edited at will, without changing scorefile operation at all! =:^) Slrn's scorefile documentation, which is what pan's format is based on: http://slrn.sourceforge.net/docs/score.txt Tho pan's format is different in at least three ways (with one being a bug: 1) Pan's regex matching is case insensitive 2) Pan lacks support for the advanced stuff such as include files and nesting (called grouping in the slrn document linked above). 3) Bug: Somewhere along the line pan's logical AND support (applying only if ALL conditions match, single colon after the Score keyword) seems to have broken, tho I seem to remember that it worked at some point in the past. So now the logic is all OR-based (applying if ANY condition matches, should be two colons after the Score keyword, but it's treating a single colon that way now too). So just write your scorefile for OR logic (see below) and always use TWO colons after the Score keyword, so if the bug is eventually fixed, you won't have to go thru and rewrite things. Note that given a reasonably wide scoring space (to +/-9999 being watched/ ignored, but beyond that should work too) and incremental scoring, in most cases it should be possible to work around the lack of nesting and logical AND support by properly adjusting your incremental scoring rules to at least get the desired scoring /range/. In case you'd find a real-world (but relatively simple) scorefile example useful, here's a link to an earlier posting of an abridged version of mine: http://permalink.gmane.org/gmane.comp.gnome.apps.pan.user/8689 -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-devel mailing list Pan-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-devel