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

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

> The question is whether it makes sense to provide an
> alternative UI for Isearch where editing the search
> string is not a special maneuver.

Really?  Is that what this is all about?

Just what is the giant inconvenience you find with
Isearch's `M-e' for editing the search string?  Not
to mention that you can always edit it directly, by
deleting chars from the end.

But let's suppose you really feel that using `M-e'
edit the search pattern using the minibuffer is too
constraining/difficult/cumbersome (choose whatever
adjective you like).

Here's another alternative you might consider, which
doesn't throw out the adorable baby with the claimed
dirty bathwater.  It's offered by `isearch+.el' via
option `isearchp-initiate-edit-commands':

,----
| isearchp-initiate-edit-commands is a variable defined in `isearch+.el'.
| 
| Its value is 
| (backward-char left-char backward-sexp backward-word left-word)
| 
| Documentation:
| Commands whose key bindings initiate Isearch edit.
| When invoked by a key sequence, Isearch edits the search string,
| applying the command to it immediately.
| 
| Commands you might want to include here are typically commands that
| move point to the left, possibly deleting text along the way.
| 
| Set this to `nil' if you always want all such commands to exit Isearch
| and act on the buffer text.
| 
| You can customize this variable.
`----

By default, for example, `backward-sexp' (e.g. `C-M-b')
initiates editing the search pattern (yes, using the
minibuffer), moving point backward a sexp from the end.

That doesn't throw out the baby.  It's on-demand only.
It's like `M-e', but it also positions point within
the search pattern to be edited.

Remove all commands from the option list and you get
vanilla Emacs Isearch behavior: only `M-e' initiates
using the minibuffer to edit the search pattern.

And we already have `M-e' automatically putting point
at the position in the search pattern where matching
fails.  (Also something from Isearch+, BTW.)

> This includes DEL doing what it does everywhere else, 

"Everywhere else" means what?  DEL in Emacs has no
"everywhere else".  It does one thing in Info, another
in an editing mode.

Just as important: Why is it important for DEL to do
"what it does everywhere" - or ANYwhere - else?

> The minibuffer starts a recursive edit.  There may be
> ways to simplify my patch, but functions which always
> return locally won't cut it.

Another feature of Isearch+:

 `C-x o' (`isearchp-open-recursive-edit') opens a recursive
 editing session, where you can do anything you like (including
 search for something different).  Using `C-M-c' closes the
 recursive editing session and resumes the search (from the
 current position where you hit `C-M-c').

Doc string:

 Invoke the editor command loop recursively, during Isearch.
 Use `C-M-c' to end the recursive edit and resume searching from there.
 Or use `C-]' to exit the recursive edit and cancel the  previous search.

That one was suggested by Juri, BTW, who said,
"Executing any code in the macro's body will also
allow doing more amazing things like temporarily
going into a recursive edit."

https://lists.gnu.org/archive/html/emacs-devel/2012-12/msg00281.html

And `C-y C-M-c' adds text to the search pattern, from
point to wherever you go to in a recursive edit.
(Command `isearchp-yank-through-rec-edit-move'.)

`C-y C-M-k' acts similarly, but adds the text from point
to wherever a key moves.  (`isearchp-yank-through-key-move'.)

`C-y C-M-m' adds text from point through a match for
another search pattern, for which you're prompted.

`C-y C-M-z' adds text from point to the next
occurrence of a character, for which you're prompted.

Those are all ways to "edit" the search pattern, and
two of them make use of recursive editing.  Still,
the baby wasn't tossed - no need to.

> The patch is about making it easier to edit the search string.

Just what's the difficulty?  That info seems to be
missing.  We've seen a solution proposed, but what
problem does it want to solve?  (Please don't answer
by just saying that the search pattern is too hard
to edit.)

> >  Why use the minibuffer at all?
> 
> So that it's natural to edit the search string during a search.

What's unnatural about using `M-e' to use the
minibuffer to edit the search pattern during a
search?

Saying something is "natural" or more so, and that
it makes it easier to do something else, is vague.

What's the actual difficulty that you think making
Isearch always use the minibuffer eases?

If the problem is editing the search pattern, and you
want to be able to use the minibuffer for that, then
we already have/do that.  Why make Isearch use the
minibuffer all the time, for everything, if the goal
is to just to let it use the minibuffer to edit the
search pattern?

> > Probably.  But, again, what has using the minibuffer
> > got to do with the keybindings a user prefers?
> 
> As stated in the original message, this feature
> is all about editing the search string.

We already use the minibuffer to do that.

> Having the same keybindings as everywhere is else

See above, about DEL - define "everywhere else".
I'm guessing you mean outside Emacs, perhaps?  In
Emacs there is no such "everywhere".  Keys can do
different things in different contexts.

> might be seen as a beneficial side effect by some
> people, but is incidental.

It's hard to tell what you think is incidental and
what you think is essential to change.  But it seems
like the actual changes you propose are far-reaching.

For 40 years Isearch has won the world by NOT using
the minibuffer (except for one-off, on-demand pattern
editing).  Zillions of search UIs have adopted the
incremental searching that Isearch pioneered.  (The
"i" in "isearch" is for "incremental".)  Why, in 2021,
would we suddenly want cram all of Isearch into using
the minibuffer?

What's the real problem you're trying to solve?  Is
it really to be able to have keys like DEL do what
you're used to them doing outside Emacs?

To be clear, I'm generally in _favor_ of providing
"alternatives" for Emacs users.

But though this was pitched as just adding an
"alternative" behavior, the code changes seem deep
and wide-ranging, 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.

Why so?