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

["Kévin Le Gouguec" <kevin.legouguec@gmail.com>]

Drew Adams <drew.adams@oracle.com> writes:

>> While isearching, I regularly find myself reaching for regular
>> navigation/editing commands (C-a, C-b, M-b, M-DEL… even C-x o, on
>> occasion), 
>
> You "regularly" want to move within the search-pattern,
> to do some editing of it besides at the end.  Is that it?
>
> But in that case, what about `C-x o'?

I'll admit that I struggle to see why I would have needed C-x o; I only
have the faintest impression that once in a blue moon I've wanted to use
it during a search.  Moving to a piece of text I was too lazy to retype
in order to kill it?  Do some light editing to the buffer before
resuming the search?  Surely nothing that I couldn't do by interrupting
the search, doing the thing, then C-s M-p (which… brings up a
minibuffer, AFAICT?  Which means all the usual navigation/editing
commands are available).

>> This thread made me discover M-e,
>
> Really?  In that case, I suggest you first try using
> that to do your editing, before asking that Isearch
> be rewritten to be minibuffer-based.  It's really not
> a big deal to use `M-e', IMO.

Sure; again, I didn't read the thread thoroughly, but my takeaway is
that the overarching tone of the proposal is indeed "it's not a big deal
to get used to isearch's idiosyncrasies, /but/ bolting an incremental
search on top of the minibuffer would [insert motivation]".

> How would you feel about what I described as existing
> in isearch+.el:
>
> Customize `isearchp-initiate-edit-commands' to include
> `beginning-of-line' (`C-a'), `backward-kill-word'
> (`M-DEL'),...?
>
> It already includes `C-b', `M-b', `C-M-b', `<left>',
> C-<left>', and `M-<left>'.  Your wish is half granted,
> even by default.

I described the proposal under discussion as "bolting an incremental
search on top of the minibuffer"; my reading of your description of
isearch+.el is "bolting regular editing/navigation keys on top of
isearch".

I don't think the distinction would matter much to me as a user, so I'd
probably be satisfied with isearch+.el (barring the manual curating of
isearchp-initiate-edit-commands).

As a theoretical greenfield implementer though, I'd probably start from
the existing minibuffer UI, since I'd get all the editing/navigation
commands "for free".

> Yes, to tell Emacs you're done editing the pattern in
> a non-trivial way you need to hit `C-s'.  Worth it, IMO.

I assume you have made this case elsewhere and I regret not taking the
time to dig it up, so apologies for making you repeat yourself: what
inherent qualities does the current, non-minibuffer-based,
implementation of isearch possess, that would be lost by using a
minibuffer?

Off the top of my head, I'd say "being able to exit a search and proceed
with my business using any key that is not bound in isearch-mode-map";
e.g. I regularly C-s a heading in org-mode and enjoy being able to C-c
C-x C-i (org-clock-in) without having to exit isearch first.

I suspect that would be implementable as a user option whose semantics
would be "if a key is neither self-inserting nor part of
isearch-mode-map, exit the minibuffer and run that key's binding".

I'm sure there are other reasons why the current implementation is
preferable though, hence my question.