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 <chet.ra...@case.edu>: >> 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. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/