From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: isearch.el patch for `M-e' to put point at mismatch position Date: Mon, 16 May 2011 15:37:20 -0700 Message-ID: References: <79A3EFE6965F48DC99409B8AC2363D2A@us.oracle.com> <87fwoe2szc.fsf@mail.jurta.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1305585451 13019 80.91.229.12 (16 May 2011 22:37:31 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 16 May 2011 22:37:31 +0000 (UTC) Cc: emacs-devel@gnu.org To: "'Juri Linkov'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 17 00:37:27 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QM6Pn-0004zS-9t for ged-emacs-devel@m.gmane.org; Tue, 17 May 2011 00:37:27 +0200 Original-Received: from localhost ([::1]:43494 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QM6Pm-0005XG-UX for ged-emacs-devel@m.gmane.org; Mon, 16 May 2011 18:37:26 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:58609) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QM6Pl-0005XA-2G for emacs-devel@gnu.org; Mon, 16 May 2011 18:37:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QM6Pj-0006e9-Uq for emacs-devel@gnu.org; Mon, 16 May 2011 18:37:24 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:32223) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QM6Pj-0006e5-Iz for emacs-devel@gnu.org; Mon, 16 May 2011 18:37:23 -0400 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p4GMbKo9006265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 May 2011 22:37:22 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p4GMbKO1010341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 May 2011 22:37:20 GMT Original-Received: from abhmt019.oracle.com (abhmt019.oracle.com [141.146.116.28]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p4GMbEs8023075; Mon, 16 May 2011 17:37:14 -0500 Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 16 May 2011 15:37:14 -0700 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcwUFuYm11aw2b0eS4K/hyzY3/HWyQAAEVlg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 In-Reply-To: <87fwoe2szc.fsf@mail.jurta.org> X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4DD1A722.0077:SCFMA922111,ss=1,fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 148.87.113.121 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:139453 Archived-At: > > 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.