Re: Bug with incremental search in menu-selection

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Sep 26,  5:51pm, Frank Terbeck wrote:
}
} In the end of the bisection process, I arrived here:
} 
} # first bad commit: [e1c0a947cc845c71dd844db44016d07922cfcefa]
}                     Read full multibyte string early for self-insert
} 
} That's workers-36496: http://www.zsh.org/mla/workers/2015/msg02418.html
} 
} I have next-to no idea about how zsh's input internals work, so that's
} about as much as I can do about this. Maybe someone else has a better
} idea.

This is actually a really old bug and the only reason the commit you
bisected is involved, is because it makes live a code path that was
never live before.

The problem is that the wrong variable has always been passed down to
wcrtomb() this bit of complist.c ... but previously we never actually
recognized wide characters in that position (instead we read them as
a series of individual bytes), and so we never previously needed to
convert them.

diff --git a/Src/Zle/complist.c b/Src/Zle/complist.c
index 01bcb7c..4337015 100644
--- a/Src/Zle/complist.c
+++ b/Src/Zle/complist.c
@@ -3300,7 +3300,7 @@ domenuselect(Hookdef dummy, Chdata dat)
 			    int len;
 
 			    memset(&mbs, 0, sizeof(mbs));
-			    len = wcrtomb(s, lastchar_wide, &mbs);
+			    len = wcrtomb(toins, lastchar_wide, &mbs);
 			    if (len < 0)
 				len = 0;
 			    insert[len] = '\0';