On Tue, Feb 24, 2015 at 10:44 PM, Chet Ramey <[email protected]> wrote: > On 2/23/15 11:13 PM, Ulf Magnusson wrote: >> text.c has the following comment: >> >> /* Bytes too short to compose character, try to wait for next byte. >> Restore the state of the byte sequence, because in this case the >> effect of mbstate is undefined. */ >> >> However, there doesn't seem to be corresponding handling for the search case. >> If e.g. the first byte of an UTF-8 'รถ' (0xC3 0xB6) character is input during >> incremental search, it ends up in the following code in input.c: >> >> if (_rl_get_char_len (mb, &ps) == -2) >> { >> /* Read more for multibyte character */ >> RL_SETSTATE (RL_STATE_MOREINPUT); >> c = rl_read_key (); >> RL_UNSETSTATE (RL_STATE_MOREINPUT); >> } >> >> rl_read_key() will in turn call rl_getc_function() -- without checking if >> there's any input available. > > Yes. In all but the rarest cases, a partially-composed multibyte > character will not require waiting for more input to be available, because > the remainder will already be in the input buffer, so the incremental > search code doesn't bother. I don't consider this a bug.
Is there something that makes waiting for input more justified in the non-search case, or is it just a case of the two code paths evolving differently? /Ulf _______________________________________________ Bug-readline mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-readline
