From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 731 invoked from network); 11 May 2008 19:11:13 -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=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; 11 May 2008 19:11:13 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 50688 invoked from network); 11 May 2008 19:11:09 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 11 May 2008 19:11:09 -0000 Received: (qmail 29833 invoked by alias); 11 May 2008 19:11:06 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 24995 Received: (qmail 29816 invoked from network); 11 May 2008 19:11:05 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 11 May 2008 19:11:05 -0000 Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.228]) by bifrost.dotsrc.org (Postfix) with ESMTP id 232A180ED172 for ; Sun, 11 May 2008 21:11:00 +0200 (CEST) Received: by rv-out-0506.google.com with SMTP id g37so1996934rvb.21 for ; Sun, 11 May 2008 12:10:59 -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=Mpb7z/uUgnEHkGg47hwPUM5yiiehc3V1O22A3Tg+tAU=; b=SJo3MqkBSZQykbGc7/SnCR9J+2oPZC3jEY3a9sR52USn3RnteoQ4gL020FnV8qSEAWZnubcOeri6Tsx4M3jg/F0X3b4ganWK9fP7Crnf9SCvR11e0HOHwg+RJNekPbaOwmIWWrhWUADsBnfIJe55kpBQGXJsK6ykmcKaO7UMxug= 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=UYGfcqcYzMH8BDe7sVAmberrxu1QAqFMpwCk3NT9V4GbbyCPHChFGEksxceBCHSxvTnyFzQSfDBe20PiwuEJuJCncgSI1tF/H3XL6VUjdxCtUWSFtf/gMKbTkFysGRgES56i9wAnOxUAhQFCLIJbgBrbVnajSWTN415jETRii68= Received: by 10.141.28.12 with SMTP id f12mr3309705rvj.1.1210533059804; Sun, 11 May 2008 12:10:59 -0700 (PDT) Received: by 10.141.153.6 with HTTP; Sun, 11 May 2008 12:10:59 -0700 (PDT) Message-ID: <237967ef0805111210k62480a14l79d73a9b1cbc4ac7@mail.gmail.com> Date: Sun, 11 May 2008 21:10:59 +0200 From: "Mikael Magnusson" To: zsh-workers Subject: Re: down-line-or-search doesn't go to last entry In-Reply-To: <20080511193145.29b04a6e@pws-pc> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <237967ef0805110723g53c9f63ct7e11d33d7daf8c64@mail.gmail.com> <20080511193145.29b04a6e@pws-pc> X-Virus-Scanned: ClamAV 0.91.2/7090/Sun May 11 20:03:45 2008 on bifrost X-Virus-Status: Clean 2008/5/11 Peter Stephenson : > > On Sun, 11 May 2008 16:23:54 +0200 > "Mikael Magnusson" wrote: > > I have {up,down}-line-or-search bound to Up/Down, and I noticed > > recently that down-line-or-search won't go to the empty entry anymore. > > Ie if you press up and then down, it will still have the previous > > entry in the cmdline, I have to press page down where I have > > down-history to get back to the empty line. > > I have been annoying myself silly with this over yet another two hours > of my life that will never come again. > > There is one bug in zlinecmp() that I've recently introduced. > > However, I don't think that's the main problem, which is the second test > for whether a search line is acceptable. In recent versions of the > shell, the test has been looking to ensure the search text *differs* > from the line you're trying it against, which obviously doesn't make > sense. It was already doing something such in 4.2. This is complicated > by the fact that until I changed it to using metafied strings the > comparisons were being done in interesting ways which have changed > subtly over the shell's history (though I haven't gone back before 4.2). > The upshot seems to be the test previously fortuitously failed due to > the fact that it was being passed the length of the current editing > line, not the length of the search string. > > I am guessing that the real point of this second test is to compare if > the line is different from the one you've just left, and hence it > shouldn't involve the search string at all, just the line you're leaving > and the line you're trying. Those more energetic may wish, as an > exercise, to compare with the archive. > > Let's see how this works. That appears to fix the problem here, thanks. -- Mikael Magnusson