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