[Top][All Lists]

[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: Chet Ramey
Subject: Re: COMP_POINT is not set correctly when there is non-ascii characters in the command line.
Date: Tue, 27 Mar 2012 14:00:10 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2

On 3/22/12 6:59 PM, address@hidden 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.

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

reply via email to

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