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: Isearch: always try to find longest successful prefix [was: move to fail position in Isearch edit] Date: Tue, 11 Nov 2008 07:07:32 -0800 Message-ID: <001901c9440f$39133c90$0200a8c0@us.oracle.com> References: <001101c943c8$adc09750$0200a8c0@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1226416113 22545 80.91.229.12 (11 Nov 2008 15:08:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 11 Nov 2008 15:08:33 +0000 (UTC) To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 11 16:09:31 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KzurP-0006Ji-8y for ged-emacs-devel@m.gmane.org; Tue, 11 Nov 2008 16:08:55 +0100 Original-Received: from localhost ([127.0.0.1]:48547 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KzuqH-0006uJ-Is for ged-emacs-devel@m.gmane.org; Tue, 11 Nov 2008 10:07:45 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KzuqC-0006tg-BL for emacs-devel@gnu.org; Tue, 11 Nov 2008 10:07:40 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kzuq9-0006tS-2f for emacs-devel@gnu.org; Tue, 11 Nov 2008 10:07:39 -0500 Original-Received: from [199.232.76.173] (port=53521 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kzuq8-0006tP-SW for emacs-devel@gnu.org; Tue, 11 Nov 2008 10:07:36 -0500 Original-Received: from acsinet12.oracle.com ([141.146.126.234]:40663) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Kzuq8-0006Go-Ra for emacs-devel@gnu.org; Tue, 11 Nov 2008 10:07:37 -0500 Original-Received: from acsinet13.oracle.com (acsinet13.oracle.com [141.146.126.235]) by acsinet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id mABF7NBX006003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 11 Nov 2008 15:07:24 GMT Original-Received: from acsmt707.oracle.com (acsmt707.oracle.com [141.146.40.85]) by acsinet13.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id mABF7eIN005209 for ; Tue, 11 Nov 2008 15:07:42 GMT Original-Received: from dradamslap1 (/24.23.165.218) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 11 Nov 2008 15:07:28 +0000 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <001101c943c8$adc09750$0200a8c0@us.oracle.com> Thread-Index: AclDyK1Gv+OEh58jRA6k9gQfj/Q7UAAQwAGQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Source-IP: acsmt707.oracle.com [141.146.40.85] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010203.49199FB2.0138:SCFSTAT928724,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 1) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:105562 Archived-At: I suggested this: > Any interest in this? I bind it to `M-e' in > `minibuffer-local-isearch-map', so `M-e M-e' puts the > cursor at the match failure position. > > If you type a search string quickly and mistype a char or > two, this lets you correct the typo without discarding > and retyping the rest of the search string: > `M-e M-e C-s'. > > (defun isearch-goto-success-end () > "Go to end of search string text that matches." > (interactive) > (goto-char (point-max)) > (let ((cmds isearch-cmds) > succ-msg) > (when (or (not isearch-success) isearch-error) > (while (or (not (isearch-success-state (car cmds))) > (isearch-error-state (car cmds))) > (pop cmds)) > (setq succ-msg (and cmds (isearch-message-state (car cmds)))) > (backward-char (- (length isearch-string) > (length succ-msg)))))) > > (define-key minibuffer-local-isearch-map > "\M-e" 'isearchp-goto-success-end) You'll notice that this would be a lot handier if Isearch always started out (and resumed after Isearch edit) by treating the search string incrementally. For example, suppose you search again with a previous search string `aaxbbb' by hitting `C-s C-s' in a buffer where there is no match for `aaxbbb' but there are matches for `aa'. Isearch fails immediately, showing the entire search string, `aaxbbb', as a failed match by highlighting it. If, however, you had typed `aaxbbb' to a fresh `C-s', then the `aa' match would be located, and the failure highlighting would correctly reflect the `aa' prefix match success and the `xbbb' suffix match failure. You could then, for example, hit RET to stop at the partial match (`aa') position. Or you could use the above code to quickly edit only the non-matching part. If, for example, the buffer contained `aapbbb' or `aabbb', then a quick 1-character change in the middle of the search string would put you on your way. Besides these benefits would be the benefit of more consistency. Isearch would always act the same (incrementally), even when it is given a complete string to start with, just as if you had typed the string a character at a time. I don't have the time to figure out what might need to be done to get this behavior, which is preferable in my opinion. Perhaps someone who is an Isearch guru (Juri?) will be interested and have the time?