From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kevin Rodgers Newsgroups: gmane.emacs.help Subject: Re: placing cursor at *start* of match in incremental search Date: Wed, 22 Jan 2003 10:22:50 -0700 Sender: help-gnu-emacs-bounces+gnu-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: <3E2ED36A.4080003@ihs.com> References: <3E2D7F8E.1050205@ihs.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1043256435 22336 80.91.224.249 (22 Jan 2003 17:27:15 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 22 Jan 2003 17:27:15 +0000 (UTC) Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18bOee-0005nu-00 for ; Wed, 22 Jan 2003 18:27:12 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18bOdS-0000PO-0B for gnu-help-gnu-emacs@m.gmane.org; Wed, 22 Jan 2003 12:25:58 -0500 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!headwall.stanford.edu!fu-berlin.de!uni-berlin.de!170.207.51.80!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 23 Original-NNTP-Posting-Host: 170.207.51.80 Original-X-Trace: fu-berlin.de 1043256166 27957388 170.207.51.80 (16 [82742]) User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:0.9.4.1) Gecko/20020406 Netscape6/6.2.2 X-Accept-Language: en-us Original-Xref: shelby.stanford.edu gnu.emacs.help:109351 Original-To: help-gnu-emacs@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: help-gnu-emacs-bounces+gnu-help-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.help:5873 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:5873 Maciej Kalisiak wrote: > Played around a bit with both approaches, and it seems the "defadvice" method > is the better of the two, at least as presented so far. The probelm with the > hook method, as shown above, is that it breaks the behaviour of an isearch > abortion. Usually, on a C-g the cursor goes back to where it was when C-s was > pressed; with the hook form above it is placed at the first character of the > match... seems the hook is called on *all* methods of ending an isearch. OTOH, > the defadvice form works properly. > > Can the hook form be somehow coaxed to do abortion properly? Use the source: `C-g' is bound in isearch-mode-map to isearch-abort, which sets isearch-success to nil before calling isearch-done, which is what runs isearch-mode-end-hook. So you could check isearch-success before calling goto-char in the hook function. -- Kevin Rodgers