Re: PATCH: (rfc) HIST_FIND_DUPS option

[Mikael Magnusson <mikachu@xxxxxxxxx>]

On 10 May 2011 01:51, Wayne Davison <wayned@xxxxxxxxxxxxxxxxxxxxx> wrote:
> On Mon, May 9, 2011 at 3:09 PM, Mikael Magnusson <mikachu@xxxxxxxxx> 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