[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#29321: Isearch hit count
From: |
Charles A. Roelli |
Subject: |
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@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.