bug#36697: 27.0.50; gnus: some articles with score 0 are killed

[Lars Ingebrigtsen <larsi@gnus.org>]

Sam Steingold <sds@gnu.org> writes:

> So what's the verdict?
> Fix the code or modify my regexp and document the "feature"?

I think is documented...  Yup:

@item Negated character classes
If you say stuff like @code{[^abcd]*}, you may get unexpected results.
That will match newlines, which might lead to, well, The Unknown.  Say
@code{[^abcd\n]*} instead.

But that doesn't mean we couldn't change it now.

>> It's just very, very old code, trying to be maximally fast.
>
> you wrote it over 20 years ago, right?
> time flies...

Almost 30 years ago, and I didn't write it -- it was Per Abrahamsen.
:-)  I would never have come up with such a great hack.

> I have no idea - but a general "code modernization", including a switch
> to lexical bindings and using return values instead of global variables
> to pass information around - would probably speed up the code.
> (and make it thread safe!)

I don't think there's any global variables used, but there's a lot of
variables with dynamic extent used to speed up scoring; yes.

That's still faster than using parameters, as far as I know.

I'm all for rewriting this...  unless it makes Gnus significantly
slower.  Usability takes precedence over code prettiness.  But computers
have gotten slightly faster the last 30 years.

So if this can be rewritten to be backwards-compatible (and fast), but
not have the negated character class quirk, that'd be nice.  I think
when Per wrote this stuff, the re-search approach was like a 10x speedup
over the loop-and-string-match approach.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no