RE: [External] : Re: [WIP PATCH] Controlling Isearch from the minibuffer

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

> You can think of my patch as (1) adding lazy highlight/count and an M-s
> prefix to the good old M-e, which is indeed a bit of work, and (2)
> adding the entirely optional minibuffer-controlled UI which only takes
> a dozen of extra lines to implement.
> 
> If you have a technical argument as to why there shouldn't be lazy
> highlight/count in the good old M-e, it won't be hard to persuade me.

I haven't said anything about #1, and I doubt that I'd
be concerned about it one way or another, unless the
changes made for it affect other things negatively.

My voice here is about #2, the "minibuffer-controlled UI".
A priori (and it's a big a priori), I'm opposed to having
Isearch use the minibuffer instead of its longstanding
implementation.

You will note the Subject line of this thread.  It seems
to speak only to #2 - controlling Isearch from the
minibuffer.

> > and IIUC, there was even talk of
> > the "alternative" arrangement being just temporary,
> > i.e., that Isearch would eventually always follow
> > your "alternative" implementation and behavior.
> 
> Where?

Dunno.  There may have been another thread that also
talked about your #2.  Or I may have (mistakenly?)
read between the lines.

Even if there will never be any proposal/attempt to
make Isearch use the minibuffer, I have the question
of why.

Why do we need/want an "alternative" implementation
of Isearch?  Different implementations will lead to
introduction of different features or different levels
of support for existing features.

What's the giant need for a minibuffer-based Isearch?