[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] READLINE_POINT with multibyte locales

From: Chet Ramey
Subject: Re: [PATCH] READLINE_POINT with multibyte locales
Date: Wed, 11 Apr 2018 13:09:21 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

On 4/10/18 7:48 AM, Koichi Murase wrote:
> (I'm sorry. I directly replied to Chet's e-mail address by mistake.
> Let me send the reply again to the mailing list.)
> Hi Chet,
> Thank you for your explanation.
> 2018-04-10 0:26 GMT+09:00 Chet Ramey <address@hidden>:
>> Because the underlying readline variable that it controls, rl_point, is
>> kept in bytes -- an index into the line buffer.
> Sorry for my poor writing, but my suggenstion is not to change the
> meaning of internal variable `rl_point', but to convert the value of
> `rl_point' to the number of characters on assigning it to `READLINE_POINT'
> and, after the execution of the shell command, to convert
> `READLINE_POINT' to the number of bytes on assiging it to `rl_point',
> i.e., `READLINE_LINE' is the number of characters while `rl_point' is
> kept to be the number of bytes.

I see what you mean, though READLINE_LINE is a string of bytes. The issue
is that the string operators bash gives you to use operate on characters,
and it's reasonable to expect that using those operators and their results
would operate on characters rather than bytes.

Thanks for looking at the impact on backwards compatibility. It looks like
the impact would be small. We'll try the patch and gauge it.

``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    address@hidden    http://tiswww.cwru.edu/~chet/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]