all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Juri Linkov'" <juri@jurta.org>
Cc: emacs-devel@gnu.org
Subject: RE: isearch.el patch for `M-e' to put point at mismatch position
Date: Mon, 16 May 2011 15:37:20 -0700	[thread overview]
Message-ID: <F9C28526F9594971A7F4AA4009881447@us.oracle.com> (raw)
In-Reply-To: <87fwoe2szc.fsf@mail.jurta.org>

> > 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	other threads:[~2011-05-16 22:37 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-16 21:36 isearch.el patch for `M-e' to put point at mismatch position Drew Adams
2011-05-16 22:14 ` Juri Linkov
2011-05-16 22:37   ` Drew Adams [this message]
2011-05-17  3:08 ` Stefan Monnier
2011-05-27 20:54   ` Drew Adams
2011-05-28  1:27 ` Stefan Monnier
2011-09-10 11:54 ` Juri Linkov
2011-09-10 16:13   ` Drew Adams
2011-09-10 16:22     ` Drew Adams
2011-09-12 11:28       ` Juri Linkov
2011-09-12 14:58         ` Drew Adams
2011-09-14 16:08           ` Juri Linkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=F9C28526F9594971A7F4AA4009881447@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=juri@jurta.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.