GNU bug report logs - #29321
Isearch hit count

Previous Next

Full log

View this message in rfc822 format

From: Drew Adams <drew.adams <at> oracle.com>
To: "Charles A. Roelli" <charles <at> aurox.ch>, Drew Adams <drew.adams <at> oracle.com>
Cc: 29321 <at> debbugs.gnu.org
Subject: bug#29321: Isearch hit count
Date: Sun, 19 Nov 2017 11:06:39 -0800 (PST)

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

However, depending on the context - in particular the size
of the search space (e.g. buffer) but also on the kind
(difficulty) of searching (e.g. char-fold, with symmetric
matches), such an approach would not necessarily always be
cheap.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.