bug#29321: Isearch hit count

[Charles A. Roelli]

> Date: Sun, 19 Nov 2017 11:06:39 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> 
> > > I don't think Isearch determines all of the hits at once (even
> > > in just the current search direction and starting from point).
> > > Instead, it searches only on demand, *incrementally*, as the
> > > name suggests.
> > 
> > Right, and that behavior is useful when doing an Isearch in, for
> > example, shell buffers, where new matches for a search string might
> > enter the buffer after the search begins, or in large buffers, where
> > finding each match would be prohibitive.  But in most other cases,
> > giving some contextual information as to how many search matches are
> > after or before point would be a cheap operation.
> 
> My point was that Isearc, so far, is designed for search
> only within the visible part of the buffer.  All of the
> possible hits in the search space are not found; hits
> are found only within the visible part of the buffer
> (and that is only by lazy-highlighting).
> 
> That doesn't mean that a different search approach couldn't
> be used, e.g., for a different search command.
> 
> And it doesn't even mean that a different approach couldn't
> be integrated with Isearch, e.g., by a user option or a
> toggle key that switches to a find-all-search-hits approach.

Sure, an interactive toggle and a corresponding defvar/defcustom to
control the default behavior would be a good fit.