bug#29321: Isearch hit count

[Drew Adams <drew.adams@oracle.com>]

> > I was thinking about this request, and thinking along these
> > lines: Where we count, push (match-# . buffer-position)
> > to an alist variable.  The variable would get reinitialized
> > when counting gets reinitialized (e.g. for a new search
> > string, direction change, or startup of Isearch).
> >
> > That alist could be used to go to any given match, either
> > during the current Isearch or later.  If they wanted, users
> > could even save copies of the alist for different searches,
> > for subsequent reuse.
> 
> A mapping from search parameters (search string, direction, etc.)
> to the matches and buffer-positions invalidates too quickly.
> Even using point-markers doesn't help when a user deletes
> a large region with former matches.

I don't see why.  Sure, if someone edits the buffer during
an Isearch recursive edit and then resumes searching it is
possible that some things might be thrown off a bit.  But
in general I think the position will be mostly accurate
(obviously different ends of the match would be recorded,
depending on the current search direction).

And even if the position recorded were sometimes off a bit,
resuming search from that position should put you where you
wanted to be almost all of the time.  IOW, it would move you
very near, even if not always exactly to, the relevant search
occurrence.  So searching from there would be right on, or
maybe one occurrence away from, the desired occurrence.

It's possible I'm not understanding you, however.  I don't
see a real problem here, but that doesn't mean there isn't
one.  Maybe you can elaborate a bit about the problem, or
maybe give an example.

> > I was thinking of binding a key during Isearch to move to
> > an occurrence by its match number.  `M-g' perhaps.  With
> > a numeric prefix arg it would move to that number.  With
> > no prefix arg it would prompt for the number (with
> > completion requiring a match against the alist).
> 
> I understand that in addition to relative counting like
> 'C-u 42 C-s' would do, you propose absolute counting like
> 'C-s M-g 42 RET'.  But a question: shouldn't 'M-g'
> exit the search since it's a global prefix key.

Yes, I was talking about moving to an absolute match
number - what you see in the prompt, not N matches
forward or backward.

I don't really care what key would be used - `M-g' was
just a suggestion.

As you know, I personally don't have a problem with
Isearch co-opting a key that currently ends Isearch,
depending on the key.  I have no problem with Isearch
using `M-g' for that (so that if you wanted to stop
Isearch and do `goto-char' you would need to do
`RET M-g c' instead of just `M-g c'.

In what I suggested you could do `C-u 42 M-g' during
Isearch, provided `isearch-allow-prefix' is non-nil.
You could alternatively do `M-g 42 RET' (replying to
a prompt for reading the number), regardless of the
value of `isearch-allow-prefix'.

(BTW, to use your `C-u 42 C-s` during Isearch, wouldn't
option `isearch-allow-prefix' also need to be non-nil?
Or didn't you intend that to be used also during Isearch?)