Re: zsh 4.3.10 history-incremental-search-backward freezes in UTF-8

[Bart Schaefer <schaefer@brasslantern.com>]

On Mar 18, 11:50am, Vincent Lefevre wrote:
} Subject: zsh 4.3.10 history-incremental-search-backward freezes in UTF-8
} 
} Is this a known problem? Has it been fixed?

I guess it's "known" since you reported it about 10 days ago. :-/

Looking back quickly at that report ... I ignored it because I have
no idea how to interpret output from "sample".  I'd never even heard
of "sample" until you referenced it there.

} I get a reproducible freeze of zsh 4.3.10 when searching the history
} backward (history-incremental-search-backward). I think the problem
} comes from the fact that the history contains command lines encoded
} in ISO-8859-1 while I'm currently under UTF-8 locales (the freeze is
} not reproducible under ISO-8859-1 locales).

Combining this information with what I see in the "sample" output, my
guess is that an attempt to iterate over a multibyte string using
the multibyte libraries is hitting a spot where interpreting ISO-8859
as UTF-8 results in some kind of failure to advance the character
index, which then causes the search to keep scanning the same history
entry repeatedly.

Probably here:

	    while (charpos < end_pos) {
		ret = mb_metacharlenconv_r(zlemetaline + charpos, &wc, &mbs);
		if (charpos <= pos && pos < charpos + ret)
		    isearch_startpos = charcount;
		charcount++;
		charpos += ret;
	    }

There needs to be some kind of sane behavior if ret == 0, or the
mb_metacharlenconv_r() function in utils.c must assure that it never
does return zero:

    if (ptr > s) {
	return 1 + (*s == Meta);	/* Treat as single byte character */
    } else
	return 0;		/* Probably shouldn't happen */

Possibly related to this thread back in November:

http://www.zsh.org/mla/workers/2009/msg01103.html

There doesn't seem to have been any resolution to that, but it's hard
to follow all the way to the end with the archive.