PATCH: (rfc) HIST_FIND_DUPS option

PATCH: (rfc) HIST_FIND_DUPS option

[Mikael Magnusson]

Add HIST_FIND_DUPS option so ctrl-r finds identical lines, useful when
you want to ctrl-o through some and it found the wrong sequence. For
example if you have this history:

command you remember
command you want to run
5000 other commands
command you remember
useless command

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, this
seems like a weird distinction to make to me (if this is the case).

patch if someone wants to try it, not for committing of course since i
didn't add docs:
http://cgit.mika.l3ib.org/cgit/zsh-cvs/commit/?id=034f471caa87

corrupted patch to look at:
diff --git a/Src/Zle/zle_hist.c b/Src/Zle/zle_hist.c
index ed524d3..51d8667 100644
--- a/Src/Zle/zle_hist.c
+++ b/Src/Zle/zle_hist.c
@@ -1415,7 +1415,9 @@ doisearch(char **args, int dir, int pattern)
 		else
 		    skip_line = isset(HISTFINDNODUPS)
 			? !!(he->node.flags & HIST_DUP)
-			: !strcmp(zt, last_line);
+			: isset(HISTFINDDUPS)
+			  ? 0
+			  : !strcmp(zt, last_line);
 	    }
 	    dup_ok = 0;
 	    /*
diff --git a/Src/options.c b/Src/options.c
index 1ce9f41..2b88c7a 100644
--- a/Src/options.c
+++ b/Src/options.c
@@ -146,6 +146,7 @@ static struct optname optns[] = {
 {{NULL, "histbeep",	      OPT_ALL},			 HISTBEEP},
 {{NULL, "histexpiredupsfirst",0},			 HISTEXPIREDUPSFIRST},
 {{NULL, "histfcntllock",      0},			 HISTFCNTLLOCK},
+{{NULL, "histfinddups",       0},			 HISTFINDDUPS},
 {{NULL, "histfindnodups",     0},			 HISTFINDNODUPS},
 {{NULL, "histignorealldups",  0},			 HISTIGNOREALLDUPS},
 {{NULL, "histignoredups",     0},			 HISTIGNOREDUPS},
diff --git a/Src/zsh.h b/Src/zsh.h
index 7f28f69..ba324ac 100644
--- a/Src/zsh.h
+++ b/Src/zsh.h
@@ -1988,6 +1988,7 @@ enum {
     HISTBEEP,
     HISTEXPIREDUPSFIRST,
     HISTFCNTLLOCK,
+    HISTFINDDUPS,
     HISTFINDNODUPS,
     HISTIGNOREALLDUPS,
     HISTIGNOREDUPS,


-- 
Mikael Magnusson

Re: PATCH: (rfc) HIST_FIND_DUPS option

[Wayne Davison]

[-- Attachment #1: Type: text/plain, Size: 1088 bytes --]

On Mon, May 9, 2011 at 3:09 PM, Mikael Magnusson <mikachu@gmail.com> 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).

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, 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.

..wayne..

Re: PATCH: (rfc) HIST_FIND_DUPS option

[Mikael Magnusson]

On 10 May 2011 01:51, Wayne Davison <wayned@users.sourceforge.net> wrote:
> On Mon, May 9, 2011 at 3:09 PM, Mikael Magnusson <mikachu@gmail.com> 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

Re: PATCH: (rfc) HIST_FIND_DUPS option

[Wayne Davison]

[-- Attachment #1: Type: text/plain, Size: 1037 bytes --]

On Mon, May 9, 2011 at 5:03 PM, Mikael Magnusson <mikachu@gmail.com> wrote:

> Yeah, but why show it again if there was an intervening other line, but not
> otherwise?
>

Well, that's the whole purpose of the no-dups option is to remove all the
duplicates that you've already rejected. With that off, zsh just tries to
avoid appearing to be buggy -- if the user hits a key to search backward and
the line doesn't change, it has the appearance of having done nothing.

This is already possible, and indeed how I have been using this feature.
>

Nice!  I had forgotten that post.

Unfortunately I don't think I can do anything from this hook to affect the
> dupness of results.


It might be interesting to have a way for that hook to affect the value of
last_line so that it could not compare as identical.

One more note on your idea of a HIST_FIND_ALL_DUPS option -- it would need
to affect other hist movement too.  I know that the arrow up/down code has a
similar avoid-the-appearance-of-doing-nothing idiom, for instance.

..wayne..