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

[Sam Steingold]

> * Lars Ingebrigtsen <ynefv@tahf.bet> [2020-07-24 17:27:45 +0200]:
>
> Sam Steingold <sds@gnu.org> writes:
>
>> `gnus-score-string' is called from `gnus-score-headers',
>> `search-func` is `re-search-backward'
>> It is called on line 2148 on `match' which is "[^a-z]\\{50\\}".
>> So, it matches for _all_ subjects - _before_ the last 3 - because it
>> searches _across_ lines!
>
> Oh, yeah, I had forgotten that -- it's a neat hack to speed up the time
> to score big groups: Calling re-search-backward is much, much faster
> than looping over the headers and using string-match.  But it does mean
> that if you have regexps like [^a-z], they have to have a \n in them,
> too.

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

>> PS. The code in gnus-score.el seems to avoid modern Emacs-Lisp features
>> like `dolist' and `when'.  Is there a (non-historical) reason for that?
>> Also, the functions are very long and thus hard to edebug.
>
> It's just very, very old code, trying to be maximally fast.

you wrote it over 20 years ago, right?
time flies...

>> I had to extract some loops into separate functions to speed up stepping.
>> Is it okay to commit?
>
> Is there a performance impact?

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!)

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1894
http://childpsy.net http://calmchildstories.com http://steingoldpsychology.com
https://americancensorship.org https://thereligionofpeace.com
Money does not "play a role", it writes the scenario.