RE: killing the result of isearch

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

> The problem here is that the result of search is
> *only* to move point and *not* to create a region of the highlighted
> matching string. So what appears on the screen carries actually very
> little meaning *because* with vanilla emacs, there is not isearch
> function (or any other search function for that matter) that creates a
> region out of that match.

Not to belabor this too much, but `query-replace' sounds
like it might be something closer to what you are looking
for.  It is exactly about finding some text and _optionally_
replacing or deleting it.

 `RET' just finds it and exits.
 `.' replaces/deletes it and exits.
 `C-w' deletes it and exits.
 `SPC' replaces/deletes it and moves to the next occurrence.
 `!' replaces/deletes all occurrences.

 You can move backward, undo, and change replacement string.

`query-replace' is _designed to act_ on the highlighted
text (the matches).  Isearch is _not_ designed to act on
it.  (But Isearch+ also let you do that, and in any number
of ways.)

The strength of Isearch is the "I" part: _incremental_
changes to the search string are reflected in the matches.
That behavior is not really available to `query-replace',
except in a roundabout, clumsy way - it was designed
for incremental replacement decisions, but not for
incrementally changing the search pattern.

> So it really is only a decoration.

Mere "decoration", if you like.  But it's decoration with
a lot of meaning.  It _shows you what matches_ your search
pattern.  How else would you know what matches?  Is seeing
the targets clearly just decoration, or is it an important
feature?

> If something should be highlighted, it should be the position
> of point, not how point found its way there, or at least the
> full region created by the search.

Dunno what you mean by the last part.  What full region
are you suggesting might be useful to highlight?  Do you
mean the region from the current search hit back to where
search started?  If you just mean full search hits then
that's the longstanding behavior.

> Anything else has little meaning in the context of isearch.

I disagree strongly here.  For search the _most important_
things to highlight (point out in some way) are the search
hits.

If I show you an aerial photo of a region, and you ask for
the locations of the cafes (or churches or playgrounds or
restrooms) don't you think it would be helpful for me to
highlight them for you?

Which also points out that Isearch is _not_ just about
navigation - moving to some search-hit location.  It's
also - perhaps mainly - about identifying/seeing the
search hits.

It's about pointing them out: highlighting them.

That's what I use it for much of the time, when working
with code, for example.  Whether I end up moving to any
search hit, even temporarily, is a separate thing.  Just
being able to see clearly the matches is often all I need.

That many other-application "find" operations highlight
only the current search hit is a drawback, IMO, not an
advantage.

And seeing all of the search hits in the current window
is especially important for an _incremental_ search
operation, where you often change the search pattern.

If you keep to the same search pattern throughout a
static "find" operation then perhaps it's not so
important to highlight all of the search hits.

Meaning no offense, I'd suggest (in hopes that it
helps) that your reaction here sounds a bit like that
of someone encountering a frying pan for the first
time and complaining that it is not as good as a deep
pot for boiling water.  A frying pan is its own thing.

Incremental search is a thing.  It has its own features
and advantages.  It's not the only way to find things,
and it was not designed as a way to find and act on
something.  It's still useful, as designed.

But Emacs offers plenty of other ways to find things
and act on them, from `query-replace' to `grep' and
`occur', and on beyond.  Most importantly, you can
roll your own - limited only by one's imagination.