[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-readline] Search with multibyte characters broken with custom r
From: |
Ulf Magnusson |
Subject: |
Re: [Bug-readline] Search with multibyte characters broken with custom rl_getc_function() (with analysis) |
Date: |
Wed, 25 Feb 2015 00:54:26 +0100 |
On Tue, Feb 24, 2015 at 10:44 PM, Chet Ramey <address@hidden> 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