bug#3746: M-r in comint mode should use isearch

[Dan Nicolaescu]

Juri Linkov <juri@jurta.org> writes:

  > >   > > The problem with that is that C-s (and C-r) already have bindings in
  > >   > > comint modes, and changing them would not be liked by most users.
  > >   > > Doing M-r and then C-s/C-r seems a bit cumbersome.
  > >   > > IMHO just using M-r for incremental history search will provide no
  > >   > > surprises for the user, and it seems like a natural extension of the
  > >   > > current behavior.
  > >   >
  > >   > Currently M-r typed in the shell buffer activates the minibuffer with
  > >   > the prompt "Previous input matching (regexp): ".  I doubt that users
  > >   > will like to see Isearch activated instead of this minibuffer.
  > >
  > > Why not?  It does provide the same functionality and it seems easier to
  > > use.  Maybe the prompt would need to be adjusted, but, IMHO, it's
  > > doubtful the users would be unpleasantly surprised by the behavior...
  > 
  > M-r has a different UI. Its main difference that it is a non-incremental
  > regexp search unlike C-s that is an incremental string search.  

Is there any reason not to have an incremental search for M-r too?

  > Both bash and the Emacs minibuffer activate Isearch on C-s, so it
  > would be natural to do the same in shell buffers.  We could try the
  > same context-dependent dwim approach used by the option of
  > `dired-isearch-filenames', i.e.  "When point is on a file name
  > initially, search file names".  So when point is on the shell prompt
  > then run Isearch on the shell history, otherwise run Isearch on the
  > shell buffer.

That sounds fine, but it's not exclusive with M-r being an incremental
search too.

We are at the beginning of a release cycle, so we can experiment, if the
users hate the change, there's enough time to change back.

  > What to do with the prompt is more difficult problem.  Bash replaces the
  > shell prompt with the search prompt.  Perhaps we should do the same.

Agreed.