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

[Drew Adams]

> I don't know what impacts it might have on the UI, but I've often
> wished (from an implementation point of view) that Isearch used
> an actual plain old minibuffer rather than mimicking one

Why?

[FWIW, I wouldn't say that Isearch mimics a minibuffer.
 But it's the case that given the place where you type
 search-pattern input Emacs users can mistake that for
 using a minibuffer.

 It's because Isearch exploits the echo-area, which users
 often mistake for the minibuffer anyway. even without,
 in effect, using it in an interaction that separately
 reads input.]

And what about from a user point of view?  What advantages?
You say you don't know what impacts it might have.  Fair
enough, I guess.

> (which doesn't necessary mean it'd be a good idea either,
> just that it would have some benefits

What benefits?

> and that the downsides were not as immediately apparent ;-).

What downsides, for implementation (e.g. compatibility
with 3rd-party code) - and for users?

The obvious way some complete rewrite/redesign should
come about, if at all, is for someone to write a separate
package that implements it independently: e.g. Mysearch,
not Isearch.  Plenty of people with try that, pound on it,
expound on its benefits and drawbacks, improve it, or
whatever.  It someone wants an "alternative" like that,
implement it separately as a real alternative, and see how
it goes.

As opposed to messing with the Isearch implementation,
which is not at all minibuffer-based.