bug-bash
[Top][All Lists]
Advanced

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

Re: COMP_POINT is not set correctly when there is non-ascii characters i


From: Yichao Yu
Subject: Re: COMP_POINT is not set correctly when there is non-ascii characters in the command line.
Date: Tue, 27 Mar 2012 14:17:34 -0400

So is it possible to set COMP_POINT as the number of characters
between 0 and rl_point (if it is also bad to break libreadline api by
setting rl_point as that.) without screwing up other part of the code?
(I hope this fix would be no more than searching for rl_point and
replace wherever necessary.)

Treating ${#COMP_LINE} separately is definitely not a good solution I
think, since there is also all kinds of related operation such as
${COMP_LINE:a:b} etc (as what is done in bash-completion package) and
if u set line=${COMP_LINE} it will be REALLY weird if ${#line} and
${#COMP_LINE} are different. (The only point for this fix might be
consistency with the manual~~)


On Tue, Mar 27, 2012 at 2:00 PM, Chet Ramey <chet.ramey@case.edu> wrote:
> On 3/22/12 6:59 PM, yyc1992@gmail.com wrote:
>
>> Bash Version: 4.2
>> Patch Level: 24
>> Release Status: release
>>
>> Description:
>>         The variable COMP_POINT is actually set to the size (not the length) 
>> of the command line before the cursor, whereas ${#COMP_LINE} returns the 
>> length of the string. This behavior make it hard to determine where the 
>> cursor is when the commandline contain non-ascii characters and it is NOT 
>> consistent with the statement in bash(1) which says these two are the same 
>> when the cursor is at the end of the line.
>
> Yes, this is an interesting dilemma.  COMP_POINT reflects the value of
> rl_point, which is readline's view of the current insertion point.
> rl_point is a byte value: the index into the readline line buffer.
> Readline handles the conversion to and from and display of multibyte
> characters internally while implementing everything as an array of bytes.
> COMP_LINE is also an array of bytes, but Posix specifies that the
> ${#word} expansion returns the number of *characters*.  Maybe the thing
> to do is to special-case COMP_LINE so thst ${#COMP_LINE} returns
> strlen(rl_line_buffer), but that's also sure to displease somebody.
>
> Chet
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>                 ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/



reply via email to

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