Re: Perplexing `COMP_POINT` value on bashcompinit tab completion

[Oliver Kiddle <okiddle@xxxxxxxxxxx>]

Bart wrote:
>
> > I use the OMZ/`bashcompinit` combination in order to write my tab completion scripts.
>
> I'll note that as soon as you introduce OMZ, things get a little murky

I wouldn't really recommend the use of bashcompinit either. It
compromises completion on zsh heavily and if you're providing the
function to users, they're unlikely to be able to use it without going
to some effort to enable it.

It's a lot cleaner to provide separate functions.

> I'm fairly certain this happens because arrays in bash are
> zero-base-indexed, whereas arrays in zsh are one-base-indexed.  So the

I don't think that's it.

> COMP_POINT is computed like this:
>
> (( COMP_POINT = 1 + ${#${(j. .)words[1,CURRENT-1]}} + $#QIPREFIX +
> $#IPREFIX + $#PREFIX ))
>
> However, "1 +" is probably wrong here because the stand-in for compgen
> re-asserts KSH_ARRAYS.  There was an attempt to fix this in

The 1 + looks right. It covers the space following the previous word
because joining the words with (j. .) doesn't account for that word
separator. It is broken if you use multiple spaces to separate words and
wouldn't be correct for completion in command position - which doesn't
matter because bashcompinit would never be used in command position.

I wonder if COMP_POINT could perhaps simply be computed with
${#LBUFFER}.

> zsh-workers articles 31031 to 30137 but the wrong fix was done,

The change there was to include the length of the current word which is
clearly wrong because that's covered by the prefix variables.

Looking over those changes, I'm really quite sceptical about most
of them in general. 29135 is also questionable. It does, strictly
speaking, bring behaviour closer to bash but the original intention
was for bashcompinit to defer to zsh's matching. Perhaps that could be
configurable with a style.

> > Zsh sends `COMP_LINE=/home/oooh_my_tab/scr a`, and the now more perplexing `COMP_POINT=25`, which adds an unexpected extra unit to what was, in the previous example, an already apparently off-by-one value.

COMP_LINE being expanded to /home/oooh_my_tab/scr seems strange. I
suspect that scr is perhaps aliased to /home/oooh_my_tab/scr. Perhaps we
do need to use $LBUFFER there too. Will need to test with some actual
bash completions.

> I don't see any obvious reason for this in the current sources, but
> what version of zsh do you have?  The "different bug" I mention above
> was present from November 2013 to January 2017 and fixed in zsh
> version 5.4.2, and that bug might explain the additional offset.

I'm inclined to suspect that a zsh from that time range is being used.

Oliver