[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-readline] Search with multibyte characters broken with custom r
From: |
Chet Ramey |
Subject: |
Re: [Bug-readline] Search with multibyte characters broken with custom rl_getc_function() (with analysis) |
Date: |
Tue, 24 Feb 2015 16:44:05 -0500 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 |
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.
Using rl_input_available is not a good synchronization mechanism for this
case. I'll have to think about what to do with it.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU address@hidden http://cnswww.cns.cwru.edu/~chet/