emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: isearch.el patch for `M-e' to put point at mismatch position


From: Drew Adams
Subject: RE: isearch.el patch for `M-e' to put point at mismatch position
Date: Mon, 16 May 2011 15:37:20 -0700

> > The attached patch makes `M-e' (`isearch-edit-string') put 
> > point at the first mismatch position (or the search-string
> > end if no mismatch).
> 
> Wouldn't this be too surprising for users?

No, I don't think so, or I wouldn't be using it (in isearch+.el), and I wouldn't
be proposing it here. ;-)

A user who hits `M-e' while looking at a search string with mismatch
highlighting will not be surprised to find the editing cursor positioned where
the highlighting began.

(This simply uses `read-from-minibuffer' with a cons INITIAL-CONTENTS argument.
Emacs doesn't take special measures when it does this.)

> Maybe there should be some
> visual indication to explain why the cursor is in the middle of the
> search string?  E.g. the same highlighting of the failed part with the
> `isearch-fail' face.

pro: For the reason you suppose.

con: It could give the impression that the highlighting is active (actively
updated), whereas it represents only a snapshot of the original state.  This
could be remedied by removing the highlighting as soon as any editing is done
(any change is made).  That would be OK.

But I really do not think it is needed.  The user just saw the highlighting,
before hitting `M-e'.

> Or more conveniently - activating the region on
> the failed part, so the user can easily delete it with one keystroke.

No, please.  C-k does the same thing, and it does not interfere, as activating
the region would.  And `C-g' after/before editing does the same thing.

There is no want of a quick way to remove the mismatched portion, once the
cursor is placed at the first mismatch position.  It is that positioning that
takes users time.  And it requires them to remember where the mismatch was.

FWIW, for a long time I did not move point to the mismatch position
automatically; I just bound `M-e', in the edit keymap, to let users move it
there on demand.  IOW, after `M-e' a second `M-e' moved point to the mismatch
position.

I used that approach for a long time, but I found this to be much better: (a) no
need to hit a key; (b) no need to remember which key does that; (c) I find I
want point positioned there 100% of the time.  For me it's a no-brainer.  But do
as you like.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]