GNU bug report logs - #29321
Isearch hit count

Previous Next

Full log

Message #17 received at 29321 <at> debbugs.gnu.org (full text, mbox):

From: charles <at> aurox.ch (Charles A. Roelli)
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 29321 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#29321: Isearch hit count
Date: Mon, 20 Nov 2017 20:25:15 +0100

> Date: Sun, 19 Nov 2017 11:06:39 -0800 (PST)
> From: Drew Adams <drew.adams <at> 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.

Previous Next

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