Re: Isearch interaction model

[Daniel Colascione <dancol@dancol.org>]

On 03/01/2018 02:39 PM, Juri Linkov wrote:
>> Thanks. I'm looking for ways we can tweak the existing default interaction
>> model, but I think we should take a broader look at how isearch works in
>> the first place. IMHO, find-and-replace should be more closely integrated
>> into isearch,
> 
> I believe we could arrive to this goal gradually by adding more isearch
> features to query-replace, and query-replace features to isearch,
> i.e. like digging a tunnel from both ends to meet in the middle.

Right. It should be easy to switch between isearch and query-replace.

> As one of first simplest steps we could try to sync their keybindings
> as much as possible, e.g. to add:
> 
> (define-key query-replace-map "\C-s" 'skip)
> (define-key query-replace-map "\C-r" 'backup)
> (define-key query-replace-map "\M-e" 'edit-replacement)

(y)

> ...
> 
>> we should have a unified history for regular and regex search,
> 
> Not sure about this, I thought more in the direction of adding separate
> histories for word search, symbol search, to be able to repeat the last
> search of the same type.  Why do you think histories should be shared?

"What" versus "how".

We have a search history because it's often the case that we want to 
repeat something we've recently done --- look up the same word, find the 
same function, and so on. It doesn't make sense to me that the exact 
mechanism we use to search for a particular thing should affect its 
recency or the way in which we recall it.

It's very easy already to casually switch between literal and regex 
isearch with M-r. Why should this distinction affect the way in which we 
recall that search?

>> and case-sensitivity, symbol-granularity, regex mode, etc. should all
>> be independently toggleable peer flags.
> 
> Do you mean customizing default search parameters, or keeping toggled
> parameters in later searches?

Both.