From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9456 invoked from network); 28 Apr 2008 10:50:48 -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.6 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 10:50:48 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 84039 invoked from network); 28 Apr 2008 10:50:38 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 28 Apr 2008 10:50:38 -0000 Received: (qmail 24752 invoked by alias); 28 Apr 2008 10:50:34 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 24890 Received: (qmail 24738 invoked from network); 28 Apr 2008 10:50:33 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 28 Apr 2008 10:50:33 -0000 Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by bifrost.dotsrc.org (Postfix) with ESMTP id 77E27808A38C for ; Mon, 28 Apr 2008 12:50:29 +0200 (CEST) Received: by wf-out-1314.google.com with SMTP id 25so4579758wfc.3 for ; Mon, 28 Apr 2008 03:50:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=VRLlRgf16841MbpMGdV40jCE3LquGfXNp93RAtCBLtg=; b=mVMjnkbBdMr5wuqPVWhz5RhkzG78iceTpyblsPZa/cZhvnk2u7KKgcIsvEM8jwTDupMkLA05pPRyKSoUDECAgv8phjd+FmL/OkL8DEi+bBOSHv3yAzGIb7kBnqnJA2w/ckOvwJNjqSipG0+nZkOnyT20vhFwJlmd5P9sD13B8q8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SeibqMlE5loAXIwCiigemoRY/uQdivDEvAm3NEJLJ1qKCFxDDss7k2Be5mx8S5cyUWhvlUCJaEW2YU0FnMcBof4UuoIrgOkmAmsbSnPMPSF6PJ5CfJLmYngc8i6NlKhz4dl2l3HSJqHG3e3kpnzudYnWyegvYh4EzHh9RYZJwbQ= Received: by 10.142.70.1 with SMTP id s1mr711825wfa.287.1209379828213; Mon, 28 Apr 2008 03:50:28 -0700 (PDT) Received: by 10.142.142.12 with HTTP; Mon, 28 Apr 2008 03:50:28 -0700 (PDT) Message-ID: <17393e3e0804280350h165f0466mb2776d9ff7ca03ae@mail.gmail.com> Date: Mon, 28 Apr 2008 06:50:28 -0400 From: "Matt Wozniski" To: zsh-workers@sunsite.dk Subject: Re: PATCH: isearch match highlighting In-Reply-To: <20080428102001.7b55074e@news01> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <17393e3e0804261727s560acff7sb6125d8f8b46b4b4@mail.gmail.com> <200804271957.m3RJvxiS004075@pws-pc.ntlworld.com> <17393e3e0804271849l30fe20bdp4008fc8247298d12@mail.gmail.com> <20080428102001.7b55074e@news01> X-Virus-Scanned: ClamAV 0.91.2/6977/Mon Apr 28 11:00:24 2008 on bifrost X-Virus-Status: Clean On Mon, Apr 28, 2008 at 5:20 AM, Peter Stephenson wrote: > On Sun, 27 Apr 2008 21:49:01 -0400 > "Matt Wozniski" wrote: > > Yep, works now - and looks very nice, though I wonder if we could set > > it up in a way that would let us change the fg or bg color of the > > text, rather than just reverse/standout/underline? > > I should get around to that before long. I don't think it should be too > hard. I'd like to use standard termcap AF/AB codes for this instead of the > hacked-in (surprise!) colors we currently use in completion, but it doesn't > seem to be that easy to set defaults etc. that way. Maybe Geoff knows > about this. Excellent - I wait with bated breath; that will be even more cool. :) > > That said, I found a regression in history-incremental-search-backward > > that's in CVS but not 4.3.6, so my guess is that it's caused by > > something in this patch (though I didn't back this patch out to > > double-check that assumption - I'm not very good at working with CVS). > > I've seen something like this, but unfortunately I can't get it to happen > reproducibly. Something might not be being initialised properly. Yep, spot on - After a backspace (backward-delete-char or vi-backward-delete-char), we pop back up to the previous search location. If the search was failing at that location, we set skip_pos to not try again at the current position, but if we then backspace again to a valid state, we don't unset skip_pos - This is why it needed two backspaces to trigger; we needed to go from a failing state, to another failing state, to a good state that was being treated as kinda-sorta-failed. I think that the right fix is just unconditionally resetting skip_pos right before we conditionally set it. Index: Src/Zle/zle_hist.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/Zle/zle_hist.c,v retrieving revision 1.50 diff -U7 -r1.50 zle_hist.c --- Src/Zle/zle_hist.c 27 Apr 2008 20:01:50 -0000 1.50 +++ Src/Zle/zle_hist.c 28 Apr 2008 10:48:05 -0000 @@ -1445,14 +1445,15 @@ } else if(cmd == Th(z_vibackwarddeletechar) || cmd == Th(z_backwarddeletechar)) { if (top_spot) { get_isrch_spot(--top_spot, &hl, &pos, &pat_hl, &pat_pos, &end_pos, &zlemetacs, &sbptr, &dir, &nomatch); patprog = NULL; nosearch = 1; + skip_pos = 0; } else feep = 1; if (nomatch) { memcpy(ibuf, nomatch == 2 ? INVALID_TEXT : FAILING_TEXT, BAD_TEXT_LEN); statusline = ibuf; skip_pos = 1;