bug#29321: Isearch hit count

[Drew Adams]

> > First, when I hit `C-s ea' I see 1248/2520, but then another
> > `C-s' shows 1249/2530 - the total has jumped by 10.
> >
> > I continue searching forward, and the numbering seems normal:
> > 1250/2530, 1251/2530.  OK, so the initial total was off by 10.
> >
> > But at match #1251 I switch to `C-r', and the match number is
> > 1241/2520: both the match number and the total are off by 10.
> >
> > On a small buffer I don't notice this problem.
> >
> > Do you see this too?  If not, maybe I patched mistakenly.
> 
> I see this too.  The problem was in too frequent updating
> of the Isearch prompt - the loop updated it after every
> max-at-a-time (default 20) matches, thus causing flickering
> (that didn't update the final number).  Now changed to show
> only the final number without showing intermediate numbers
> (that are invalid during counting anyway).
> 
> Please try a new patch, it removes flickering:

OK, I applied the new patch.

Here's my feedback, in case it helps.

For my own code, after the update search seems very slow.
Just mentioning that - not that it's relevant.

For vanilla Emacs after the update:

1. When I repeat searching quickly the count can freeze
   (not get updated), and when I stop or slow down, and
   then start (repeat) again, it is still frozen.

2. When that's happened and I reverse direction, it's
   also frozen, even without repeating quickly.  And
   what's worse, the match number is completely wrong.
   E.g., if I'm near the buffer beginning the match
   number is near the end.  Perhaps it is the complement
   (numbering from the end and not from the beginning,
   when C-M-r direction.

In general, the numbers seem quite messed up now.
I can go to the end of the file and get different
numbers for the last match, neither of which is the
highest match number (i.e., not = total).

BTW, with the previous update I'm pretty sure I at
one point saw the same thing about the numbering
switching to the complement (might not be the exact
complement).  I even thought that might be intended,
and so I reworded the doc string of the option to fit
that.  But afterward I never saw that again yesterday.

See attached screenshot.  Note that this was a new
search with the same input as a previous search.
But once it has the wrong numbering it seems to stick
with the "complement" numbers.

Dunno how much this helps.  I again applied the patch
manually.  I've attached the resulting file - perhaps
you can diff it against what it should be, to see if
it is faithful or I made a mistake.  That might save
us some time, if I did make a mistake.  I don't want
to provide misleading feedback.

Less relevant - just personal opinion: I prefer the
numbering in the prefix form CURRENT/TOTAL, rather
than the suffix, I think.  But I could change my mind.
What are the reasons you prefer it as a suffix - or is
it just better in terms of implementation/performance?

BTW: I just noticed that the doc string for the option
is now wrong, since it still says "CURRENT/TOTAL".
Maybe you should to change it to just say something
like "show the current match number and the total
number of..."

HTH, and thanks for working on this.  - Drew

isearch-2018-10-27a-AFTER-JURI-10-28a.el
Description: Binary data

throw-isearch-count-2018-10-28.png
Description: PNG image