Re: [Bug-readline] Search with multibyte characters broken with custom rl_getc_function() (with analysis)

[Chet Ramey]

On 2/24/15 6:54 PM, Ulf Magnusson wrote:
> 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?

The function that the incremental search code uses to read an entire
multibyte character is used in a number of places in readline.  It's
the function that gets called when you need to read an entire multibyte
character to complete some operation.  That's its use here.

Chet

-- 
``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/