From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16714 invoked by alias); 10 May 2011 00:03:12 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 29210 Received: (qmail 15326 invoked from network); 10 May 2011 00:03:07 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 Received-SPF: pass (ns1.primenet.com.au: SPF record at _spf.google.com designates 209.85.220.171 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=U7o5tVZ3fstjZgxXg55t/Q+TF7DOJfaj9lnmCFqfAV8=; b=A+pEitDR7iFhRNsiJ9tfE6dUvNpg2XgtJR9iTf94x1U7O+a44KX5jaEG5+UaWl2IsK sr20DhBuCyoClyVq0lX0m4x0IclPlEe+Gk9pIevrtS2RAGz1TTUMaDO2fqG0vcWhPFKf 3cmHuBOap7IrNc7TdXilKz22KIapqu4NRTpk4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=FygPxNjquO71J5A+86TuyS4SlI2iU8CX6XQTapVmAUmLcsVvATDPnb/q25vvHsT+Vs 8GpOZ/zebTA3fhikveJ6NTtb7iv+WX2DQPa/d6W43cnyVxIHiw8Xg3rNANAJ3po/xu47 dQ+8/KJ4a6xHdiU5FSdDWkf76+Cv/HZfABxrk= MIME-Version: 1.0 In-Reply-To: References: Date: Tue, 10 May 2011 02:03:00 +0200 Message-ID: Subject: Re: PATCH: (rfc) HIST_FIND_DUPS option From: Mikael Magnusson To: Wayne Davison Cc: zsh workers Content-Type: text/plain; charset=UTF-8 On 10 May 2011 01:51, Wayne Davison wrote: > On Mon, May 9, 2011 at 3:09 PM, Mikael Magnusson wrote: >> >> I am currently unsure why unsetting HIST_FIND_NO_DUPS doesn't have this >> behaviour already. Possibly it only finds the same line after finding >> another line in between that also matches the search > > Exactly. Under normal circumstance, if the user has rejected a particular > line as not being one that they want to run, showing them the same line > isn't usually very useful to them (and may indeed be confusing). Yeah, but why show it again if there was an intervening other line, but not otherwise? Ie with this history : barfoo : foobar : ninja : foobar : barfoo : foobar searching for foo will give you line 6, 5 and 4, but not 2, then 1. I just don't see the point of this distinction. > I don't particularly like the HIST_FIND_DUPS option. If you named it > HIST_FIND_ALL_DUPS I'd like it a bit better. Yeah, the name is not set in stone :). > But I do wonder if there isn't > a better solution to help you solve this particular search idiom (one where > you're really searching not just for a line, but for a set of lines). For > instance, it would be interesting to be able to ask zsh to show a line or > two of context following the line as you visit each matching line. In such > a search, it would make a lot of sense to show the user another identical > line that has differing context, so that would be the default. This is already possible, and indeed how I have been using this feature. http://www.zsh.org/mla/workers/2010/msg00720.html Unfortunately I don't think I can do anything from this hook to affect the dupness of results. -- Mikael Magnusson