[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#36697: 27.0.50; gnus: some articles with score 0 are killed
From: |
Lars Ingebrigtsen |
Subject: |
bug#36697: 27.0.50; gnus: some articles with score 0 are killed |
Date: |
Fri, 24 Jul 2020 17:27:45 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
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.
> 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.
> I had to extract some loops into separate functions to speed up stepping.
> Is it okay to commit?
Is there a performance impact?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no