On Wed, Mar 28, 2012 at 10:48 PM, Chet Ramey <chet.ra...@case.edu> wrote:
> On 3/27/12 2:17 PM, Yichao Yu wrote:
>> 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.)
>
> I was going to respond that to break the relationship between COMP_POINT
> and rl_point makes it very difficult, if not impossible, to identify the
> character under the cursor when completion is attempted, but I'm not
> sure how much that actually matters. You can't assign rl_point using
> this, so that's not an issue either.
Sorry didn't get it. Bash can always internally access rl_point (to
"identify the character under the cursor") whether or not it is the
same with COMP_POINT and the script CANNOT "identify the character
under the cursor" using current value of COMP_POINT since
${COMPLINE:blah:blah} substitution count character instead of byte.
And this really matters, see the bash-completion bug report I link
below.
(Agree that rl_point should be kept the locale independent byte
counting value as what it is now.)
>
> Pretty much everything else in bash uses characters, which may be bytes
> depending on the locale.
>
> Can someone who's more familiar with the bash completion package tell me
> whether or not it uses COMP_POINT at all? That's about that only thing
> I can think of that would use it.
It DOES use COMP_POINT. And this is the most annoy thing and also how
I notice the issue. I reported a bug for bash-completion here
(https://alioth.debian.org/tracker/?func=detail&atid=413095&aid=313583&group_id=100114)
and soon discovered this is a bush issue.
Yichao Yu
>
> Chet
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
