On Tue, 2006-05-23 at 08:00 -0700, Mark Sapiro wrote:

The regexp entry is compiled in re.VERBOSE mode. This can be good, but also causes problems as the 'help' doesn't mention this. Further, the description says 'Topic keywords, one per line, to match against each message.' The implication is if I put

one two three

in the regexp box, that this topic will match keywords 'one', 'two' or 'three', but actually it matches only 'onetwothree'.

I see several ways to address this.

1. change the processing of this field to effectively join the lines with '|' - presumably this will break existing multiline entries, but possibly they (at least ones which already contain '|') can be converted.

2. do 1) as a list or mm_cfg option which defaults to not doing it.

3. change the description and help for the regexp to correctly reflect what happens.

What do others think?

I have a hard time imagining that anyone would enter

one two three

and not expect it to match 'one|two|three', so I think I'd opt for 1. I'm not in favor of yet another configuration variable to control this. OTOH, I've never really received much feedback on the whole topics features (thus the dearth of responses to your question ;) so I don't really have a good sense of how people are using this, if they are at all.

I'm not sure the verbose interpretation of the text box is the most useful. The other option is to use some special prefix character at the front of the regexp to indicate whether it should be verbose or not. It would have to be something that is impossible in the first position, and it seems like | would be a good choice. Thus if | were in the first position, you'd interpret that to mean each line should be joined with | but if not, then you interpret the entire regexp as a verbose pattern.

Thoughts? -Barry

Barry Warsaw wrote:

On Tue, 2006-05-23 at 08:00 -0700, Mark Sapiro wrote:

...

The regexp entry is compiled in re.VERBOSE mode. This can be good, but also causes problems as the 'help' doesn't mention this. Further, the description says 'Topic keywords, one per line, to match against each message.' The implication is if I put

one two three

in the regexp box, that this topic will match keywords 'one', 'two' or 'three', but actually it matches only 'onetwothree'.

I see several ways to address this.

1. change the processing of this field to effectively join the lines with '|' - presumably this will break existing multiline entries, but possibly they (at least ones which already contain '|') can be converted.

<snip> > >I have a hard time imagining that anyone would enter > >one >two >three > >and not expect it to match 'one|two|three', so I think I'd opt for 1. >I'm not in favor of yet another configuration variable to control this. >OTOH, I've never really received much feedback on the whole topics >features (thus the dearth of responses to your question ;) so I don't >really have a good sense of how people are using this, if they are at >all.

I've thought about this some more and what I'm currently thinking is if the topic regexp is multiline, leave it as is in topics, but before compiling it for use, split the lines and then rejoin them with "|", and compile not in VERBOSE mode.

I think this would be the natural interpretation from the existing explanation.

Then, in order to handle existing multiline topic regexps without breaking them, add code to versions.py to test stored_state.data_version and if it's less than the appropriate value, go through topics and convert any multiline regexp to a single line by deleting unescaped whitespace and comments.

I'm not sure the verbose interpretation of the text box is the most useful. The other option is to use some special prefix character at the front of the regexp to indicate whether it should be verbose or not. It would have to be something that is impossible in the first position, and it seems like | would be a good choice. Thus if | were in the first position, you'd interpret that to mean each line should be joined with | but if not, then you interpret the entire regexp as a verbose pattern.

This seems to me to be more of a kludge than my idea of converting the old multiline regexps and just dropping verbose mode all together.

-- Mark Sapiro msapiro@value.net The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

At 8:33 PM -0700 2006-05-25, Mark Sapiro wrote:

There is currently a user option to receive (or not) all posts which don't match any topic. Is this what you mean?

Yurffhh.

/me removes foot from mouth

Yes.

/me reinserts food

-- Brad Knowles, brad@stop.mail-abuse.org

"Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety."

 -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
 Assembly to the Governor, November 11, 1755

LOPSA member since December 2005. See http://www.lopsa.org/.

On 5/25/06 8:29 PM, "Mark Sapiro" msapiro@value.net wrote:

I've thought about this some more and what I'm currently thinking is if the topic regexp is multiline, leave it as is in topics, but before compiling it for use, split the lines and then rejoin them with "|", and compile not in VERBOSE mode.

I think you need to strip any trailing | characters from the strings in the resulting list before joining with |.

Otherwise, you might build one||two||three Which clearly isn't what is wanted.

Hmmm...I guess I mean "up to one trailing | character"...in case someone really wanted one||two for some really strange reason.

I think this would be the natural interpretation from the existing explanation.

I agree.

When we first installed a Mailman version with topic support, I messed around with it, and it didn't work. Since I didn't care much, I ignored the problem rather than figuring out what I was doing wrong. (This thread has made that obvious, of course.)

--John

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

I agree that one|two|three makes more sense than onetwothree. I certainly would have expected the former.

On 24-May-06, at 1:12 PM, Barry Warsaw wrote:

OTOH, I've never really received much feedback on the whole topics features (thus the dearth of responses to your question ;) so I don't really have a good sense of how people are using this, if they are at all.

Just for the record, linuxchix actually does use the topics on one of our lists (used for courses, so we don't have to set up a new list anytime someone wants to give a few lessons on a subject) and I haven't gotten any complaints from our users aside from the odd "please make sure you've got the right subject tag for this course!" stuff.

Of course, this could mean that no one uses the topic functionality 'cause they'd rather use clever mutt rules to organize their mail. ;)
But I'll assume that the lack of comment on a list that's been running for years is probably a good sign that the topic parser does its job.

My only problem with the topics came when I had to explain it to users who might not understand regular expressions. Never was terribly satisfied with this one: http://list.org/mailman-member/node30.html

Terri -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEfH8kYWvHDqWmQaoRAiF8AJ9r+25W9TEZUJ3u00p6SQCdpR7otgCgvanz o0MZkqzjx/zHIMMEFNZcAOo= =ZsSL -----END PGP SIGNATURE-----