PATCH: accept-and-infer-next-history is broken?

[Wayne Davison <wayned@users.sourceforge.net>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1936 bytes --]

On Sat, 26 May 2001, Bart Schaefer wrote:
> I DON'T want inferences to skip over the expired history slots and use
> what follows ... I'd rather have it feep at me.

Sounds like a nice idea.  I can even think of a fairly easy way to do
this, which I can implement after 4.0.1 gets released.

> So whether the algorithm needs to always search from the bottom
> depends on what "we have a line in the history below us" means.

I've been reflecting on this some more, and, I think I may like my
alternate approach better (i.e. always search from the bottom, at least
in the case of accept-and-infer-n-h).  The main reason for this is that
it gives the user the choice of how to pick the next history item.  If
you want to proceed in exactly the same sequence as before, use
accept-line-and-down-history.  If you want to make a new inference from
the current line, use accept-and-infer-next-history (which does a new
search).  It would even be logically equivalent to pressing CR +
up-arrow + infer-next-history, so that even argues in its favor, IMO.

> } Finally, I changed the function to be like a-l-a-down-history in
> } that it does not set "done = 1" if the infer fails.
>
> What practical effect does that have, exactly?

Translation:  if it can't infer a new line, it feeps and doesn't accept
the line either.  This is how accept-line-and-down-history works, and I
thought that it was a good idea for accept-and-infer-next-history to
work this way too.

OK, so here's an alternate patch to my first one.  This version does not
change the way infer-next-history works.  This allows the user to press
up-arrow and infer-next-history to try to find a match further back in
the history after each infer-next-history.  One way that this is useful
is that if you're using accept-and-infer-next-history over and over
again and you end up in the wrong sequence, using up-arrow +
infer-next-history should get you back on track.

..wayne..

[-- Attachment #2: New infer-next-history patch --]
[-- Type: TEXT/PLAIN, Size: 1817 bytes --]

Index: Src/Zle/zle_hist.c
--- Src/Zle/zle_hist.c	2000/02/23 15:18:49	1.1.1.14
+++ Src/Zle/zle_hist.c	2001/05/26 06:36:02
@@ -252,7 +252,7 @@
 
     if (!(he = movehistent(quietgethist(histline), 1, HIST_FOREIGN)))
 	return 1;
-    zpushnode(bufstack, ztrdup(ZLETEXT(he)));
+    zpushnode(bufstack, ztrdup(he->text));
     done = 1;
     stackhist = he->histnum;
     return 0;
@@ -891,23 +891,29 @@
 	kungetct = savekeys;
 }
 
+static Histent
+infernexthist(Histent he, char **args)
+{
+    for (he = movehistent(he, -2, HIST_FOREIGN);
+	 he; he = movehistent(he, -1, HIST_FOREIGN)) {
+	if (!metadiffer(he->text, (char *) line, ll))
+	    return movehistent(he, 1, HIST_FOREIGN);
+    }
+    return NULL;
+}
+
 /**/
 int
 acceptandinfernexthistory(char **args)
 {
     Histent he;
 
+    if (!(he = infernexthist(hist_ring, args)))
+	return 1;
+    zpushnode(bufstack, ztrdup(he->text));
     done = 1;
-    for (he = movehistent(quietgethist(histline), -2, HIST_FOREIGN);
-	 he; he = movehistent(he, -1, HIST_FOREIGN)) {
-	if (!metadiffer(ZLETEXT(he), (char *) line, ll)) {
-	    he = movehistent(he, 1, HIST_FOREIGN);
-	    zpushnode(bufstack, ztrdup(ZLETEXT(he)));
-	    stackhist = he->histnum;
-	    return 0;
-	}
-    }
-    return 1;
+    stackhist = he->histnum;
+    return 0;
 }
 
 /**/
@@ -916,15 +922,10 @@
 {
     Histent he;
 
-    for (he = movehistent(quietgethist(histline), -2, HIST_FOREIGN);
-	 he; he = movehistent(he, -1, HIST_FOREIGN)) {
-	if (!metadiffer(ZLETEXT(he), (char *) line, ll)) {
-	    he = movehistent(he, 1, HIST_FOREIGN);
-	    zle_setline(he);
-	    return 0;
-	}
-    }
-    return 1;
+    if (!(he = infernexthist(quietgethist(histline), args)))
+	return 1;
+    zle_setline(he);
+    return 0;
 }
 
 /**/