* PATCH: (rfc) HIST_FIND_DUPS option
@ 2011-05-09 22:09 Mikael Magnusson
2011-05-09 23:51 ` Wayne Davison
0 siblings, 1 reply; 4+ messages in thread
From: Mikael Magnusson @ 2011-05-09 22:09 UTC (permalink / raw)
To: zsh workers
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: PATCH: (rfc) HIST_FIND_DUPS option
2011-05-09 22:09 PATCH: (rfc) HIST_FIND_DUPS option Mikael Magnusson
@ 2011-05-09 23:51 ` Wayne Davison
2011-05-10 0:03 ` Mikael Magnusson
0 siblings, 1 reply; 4+ messages in thread
From: Wayne Davison @ 2011-05-09 23:51 UTC (permalink / raw)
To: Mikael Magnusson; +Cc: zsh workers
[-- 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..
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: PATCH: (rfc) HIST_FIND_DUPS option
2011-05-09 23:51 ` Wayne Davison
@ 2011-05-10 0:03 ` Mikael Magnusson
2011-05-10 5:08 ` Wayne Davison
0 siblings, 1 reply; 4+ messages in thread
From: Mikael Magnusson @ 2011-05-10 0:03 UTC (permalink / raw)
To: Wayne Davison; +Cc: zsh workers
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: PATCH: (rfc) HIST_FIND_DUPS option
2011-05-10 0:03 ` Mikael Magnusson
@ 2011-05-10 5:08 ` Wayne Davison
0 siblings, 0 replies; 4+ messages in thread
From: Wayne Davison @ 2011-05-10 5:08 UTC (permalink / raw)
To: Mikael Magnusson; +Cc: zsh workers
[-- 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..
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-05-10 5:08 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-05-09 22:09 PATCH: (rfc) HIST_FIND_DUPS option Mikael Magnusson
2011-05-09 23:51 ` Wayne Davison
2011-05-10 0:03 ` Mikael Magnusson
2011-05-10 5:08 ` Wayne Davison
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).