PATCH: muddled completion search status

PATCH: muddled completion search status

[Oliver Kiddle]

If a completion match search is active, then cursors/tab etc are used to
select a different match and then searching is restarted, the old status
(wrapped/failed etc) is included in the status line despite the search
string being empty.

There's a further feature where if you press Ctrl-S (or whatever) again,
it will restore the last search string used. This feature is also
triggered if your next key is that for a reverse search. I found this to
be confusing. The following will only restore that last search if you do
the search twice in the same direction.

Oliver

diff --git a/Src/Zle/complist.c b/Src/Zle/complist.c
index 2c7ec58..9c5b4ec 100644
--- a/Src/Zle/complist.c
+++ b/Src/Zle/complist.c
@@ -3271,13 +3271,15 @@ domenuselect(Hookdef dummy, Chdata dat)
                 }
                 if (!ins) {
                     if (was) {
-                        if (!*msearchstr && lastsearch) {
+                        if (!*msearchstr && lastsearch &&
+			    back == (mode == MM_BSEARCH)) {
                             msearchstr = dupstring(lastsearch);
                             mode = 0;
                         }
                     } else {
                         msearchstr = "";
                         msearchstack = NULL;
+			msearchstate = MS_OK;
                     }
                 } else {
 		    if (cmd == Th(z_selfinsertunmeta)) {

Re: PATCH: muddled completion search status

[Oliver Kiddle]

I wrote:
> There's a further feature where if you press Ctrl-S (or whatever) again,
> it will restore the last search string used. This feature is also
> triggered if your next key is that for a reverse search.

After checking, I noticed that this is exactly the same for history
incremental search. Again, I think it is better not to restore the
previous search string if the search direction has changed.

This also adds brief documentation of the feature.

Oliver

diff --git a/Doc/Zsh/zle.yo b/Doc/Zsh/zle.yo
index 16d661f..ac66ea9 100644
--- a/Doc/Zsh/zle.yo
+++ b/Doc/Zsh/zle.yo
@@ -1360,7 +1360,9 @@ item(tt(clear-screen))(
 Clear the screen, remaining in incremental search mode.
 )
 item(tt(history-incremental-search-backward))(
-Find the next occurrence of the contents of the mini-buffer.
+Find the next occurrence of the contents of the mini-buffer. If the
+mini-buffer is empty, the most recent previously used search string is
+reinstated.
 )
 item(tt(history-incremental-search-forward))(
 Invert the sense of the search.
diff --git a/Src/Zle/zle_hist.c b/Src/Zle/zle_hist.c
index cc66f99..0b3b9e7 100644
--- a/Src/Zle/zle_hist.c
+++ b/Src/Zle/zle_hist.c
@@ -1598,7 +1598,7 @@ doisearch(char **args, int dir, int pattern)
 	    dir = odir;
 	    skip_pos = 1;
 	rpt:
-	    if (!sbptr && previous_search_len) {
+	    if (!sbptr && previous_search_len && dir == odir) {
 		if (previous_search_len > sibuf - FIRST_SEARCH_CHAR - 2) {
 		    ibuf = hrealloc((char *)ibuf, sibuf,
 				    (sibuf + previous_search_len));

Re: PATCH: muddled completion search status

[Bart Schaefer]

On Jun 17, 12:35am, Oliver Kiddle wrote:
}
} I wrote:
} > There's a further feature where if you press Ctrl-S (or whatever) again,
} > it will restore the last search string used. This feature is also
} > triggered if your next key is that for a reverse search.
} 
} After checking, I noticed that this is exactly the same for history
} incremental search. Again, I think it is better not to restore the
} previous search string if the search direction has changed.

Unless I misunderstand you, repeating a search in emacs searches again
for the last-searched-for string no matter which direction the new
search is going.  The same is true for vi's "n" or "N" command for
searching again up/downward.  Why do you think it's wrong to restore
the last search string?  I would prefer not to break similarity (I won't
go so far as to say "compatibility") with emacs in this regard.

So maybe I'm just not following what you mean.

Re: PATCH: muddled completion search status

[Greg Klanderman]

>>>>> On June 16, 2015 Bart Schaefer <schaefer@brasslantern.com> wrote:

> Unless I misunderstand you, repeating a search in emacs searches again
> for the last-searched-for string no matter which direction the new
> search is going.  The same is true for vi's "n" or "N" command for
> searching again up/downward.  Why do you think it's wrong to restore
> the last search string?  I would prefer not to break similarity (I won't
> go so far as to say "compatibility") with emacs in this regard.

If I understand, he's actually making it more emacs-compatible.

Emacs only restores your last search when you hit the same direction
search keys twice in a row; if you hit C-s C-r is does not restore the
last search, it merely switches direction.

Greg

Re: PATCH: muddled completion search status

[Oliver Kiddle]

Bart wrote:
> Unless I misunderstand you, repeating a search in emacs searches again
> for the last-searched-for string no matter which direction the new
> search is going.  The same is true for vi's "n" or "N" command for
> searching again up/downward.  Why do you think it's wrong to restore
> the last search string?  I would prefer not to break similarity (I won't
> go so far as to say "compatibility") with emacs in this regard.
> 
> So maybe I'm just not following what you mean.

This is not the reuse of the current search string which is what you
describe but a feature where an older, previous search string from a
past search gets reinstated:

% echo one
% echo two
% ^Recho^J
% echo three
% ^R^R
bck-i-search: echo_

When the current search string is empty, invoking either of
history-incremental-search-for/back-ward will reinstate an older search.
With my change, a direction change suppresses this.

Oliver