Re: Isearch interaction model

[Daniel Colascione]

On 03/08/2018 02:41 PM, Juri Linkov wrote:
> > > > The isearch mode should be attached to the history item. C-M-s M-p and
> > > > C-s
> > > > M-p should have the same effect: the "mode" is only a default for a new
> > > > search. If the last search was a regex search, it'll put in you regex
> > > > search mode.
> > >
> > > But what about keeping current behavior where C-M-s M-p pulls only
> > > regexps from the regexp history.  Should we break backward compatibility
> > > in how it used to work?
> >
> > I think that behavior is an artifact of the current implementation, not
> > something desirable.
>
> String and regexp searches are fundamentally different in nature.

Why? I use them as different ways of accomplishing the same goal: 
finding something in a buffer.

> Regexps are useless in string-based modes, whereas strings in isearch
> are interpreted by different rules according to mode: word/case-fold/...
> e.g. it makes sense to switch from case-fold mode to word mode, but
> not from regexp mode to literal mode.

But people _do_ switch from regex to literal mode and back. That's why 
M-r is a convenient isearch binding for doing exactly that, and on 
prevision occasions when this topic has come up for discussion, others 
have indicated that they use this M-r binding.

> But it you want to share string and regexp histories, it's easy to implement
> by another layer of indirection like for query-replace history variables:
>
> (defcustom query-replace-from-history-variable 'query-replace-history
> (defcustom query-replace-to-history-variable 'query-replace-history

Sure. It's possible to make this behavior customizable.