Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: PATCH: isearch match highlighting
- X-seq: zsh-workers 24890
- From: "Matt Wozniski" <godlygeek@xxxxxxxxx>
- To: zsh-workers@xxxxxxxxxx
- Subject: Re: PATCH: isearch match highlighting
- Date: Mon, 28 Apr 2008 06:50:28 -0400
- 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=
- In-reply-to: <20080428102001.7b55074e@news01>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <godlygeek@xxxxxxxxx> <17393e3e0804261727s560acff7sb6125d8f8b46b4b4@xxxxxxxxxxxxxx> <200804271957.m3RJvxiS004075@xxxxxxxxxxxxxxxxxxx> <17393e3e0804271849l30fe20bdp4008fc8247298d12@xxxxxxxxxxxxxx> <20080428102001.7b55074e@news01>
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).
<snip testcase>
>
> 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;
Messages sorted by:
Reverse Date,
Date,
Thread,
Author