From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18415 invoked from network); 28 Apr 2008 11:03:19 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.4 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 28 Apr 2008 11:03:19 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 88955 invoked from network); 28 Apr 2008 11:03:15 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 28 Apr 2008 11:03:15 -0000 Received: (qmail 2955 invoked by alias); 28 Apr 2008 11:03:11 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 24891 Received: (qmail 2936 invoked from network); 28 Apr 2008 11:03:10 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 28 Apr 2008 11:03:10 -0000 Received: from cluster-g.mailcontrol.com (cluster-g.mailcontrol.com [85.115.41.190]) by bifrost.dotsrc.org (Postfix) with ESMTP id 808CD808A38A for ; Mon, 28 Apr 2008 13:03:07 +0200 (CEST) Received: from cameurexb01.EUROPE.ROOT.PRI ([62.189.241.200]) by rly29g.srv.mailcontrol.com (MailControl) with ESMTP id m3SB34fJ032117 for ; Mon, 28 Apr 2008 12:03:04 +0100 Received: from news01.csr.com ([10.103.143.38]) by cameurexb01.EUROPE.ROOT.PRI with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Apr 2008 12:03:02 +0100 Received: from news01.csr.com (localhost.localdomain [127.0.0.1]) by news01.csr.com (8.14.2/8.13.4) with ESMTP id m3SB33KS020869 for ; Mon, 28 Apr 2008 12:03:03 +0100 Received: from csr.com (pws@localhost) by news01.csr.com (8.14.2/8.14.2/Submit) with ESMTP id m3SB2xS7020865 for ; Mon, 28 Apr 2008 12:03:03 +0100 Message-Id: <200804281103.m3SB2xS7020865@news01.csr.com> X-Authentication-Warning: news01.csr.com: pws owned process doing -bs To: zsh-workers@sunsite.dk Subject: Re: PATCH: isearch match highlighting In-reply-to: <17393e3e0804280350h165f0466mb2776d9ff7ca03ae@mail.gmail.com> References: <17393e3e0804261727s560acff7sb6125d8f8b46b4b4@mail.gmail.com> <200804271957.m3RJvxiS004075@pws-pc.ntlworld.com> <17393e3e0804271849l30fe20bdp4008fc8247298d12@mail.gmail.com> <20080428102001.7b55074e@news01> <17393e3e0804280350h165f0466mb2776d9ff7ca03ae@mail.gmail.com> Comments: In-reply-to "Matt Wozniski" message dated "Mon, 28 Apr 2008 06:50:28 -0400." Date: Mon, 28 Apr 2008 12:02:59 +0100 From: Peter Stephenson X-OriginalArrivalTime: 28 Apr 2008 11:03:03.0188 (UTC) FILETIME=[6DD5FD40:01C8A91F] X-Scanned-By: MailControl A-08-50-01 (www.mailcontrol.com) on 10.71.0.139 X-Virus-Scanned: ClamAV 0.91.2/6977/Mon Apr 28 11:00:24 2008 on bifrost X-Virus-Status: Clean "Matt Wozniski" wrote: > I think that the right fix is just unconditionally resetting skip_pos > right before we conditionally set it. Thanks, that looks fine and I even know basically why: I just added the "nosearch" variable to optimise out a search when we're backtracking since we know whether it succeeded or failed at the position in question. That means skip_pos isn't handled quite the same way it used to be, since it's in the optimised out code, and in particular it isn't reset when we don't search (before it would have been even on a failure). As you've reset it at exactly the point nosearch is set I think that should cover everything. -- Peter Stephenson Software Engineer CSR PLC, Churchill House, Cambridge Business Park, Cowley Road Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070