Re: Perplexing `COMP_POINT` value on bashcompinit tab completion

[Bart Schaefer <schaefer@brasslantern.com>]

On Sat, Jul 21, 2018 at 4:15 AM, Geoff Wing <gcw@zsh.org> wrote:

Hmm, did this get trapped as spam or something?  Why did Geoff need to
forward it?

> ---------- Forwarded message ----------
> From: "Saverio M." <saverio.pub2@gmail.com>
> To: zsh-workers@zsh.org
> Cc:
> Bcc:
> Date: Sat, 21 Jul 2018 11:31:02 +0200
> Subject: Perplexing `COMP_POINT` value on bashcompinit tab completion
> Hello!
>
> 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, because it sets a bunch of options and key mappings that may
change some expected behavior.

> When typing:
>
> ```sh
> $ scr <tab>
> ```
>
> Bash sends to the completion script the env vars `COMP_LINE=scr ` and `COMP_POINT=4`. The number `4` is, intuitively, the position of the cursor (and the size of the `COMP_LINE` string).
>
> Zsh sends `COMP_LINE=/home/oooh_my_tab/scr `, which is different while correct nonetheless, but sends `COMP_POINT=23`, which is perplexing, since the position of the cursor is `22`.

I'm not sure why zsh is expanding the full path to "scr" here (see
above about OMZ), but:

I'm fairly certain this happens because arrays in bash are
zero-base-indexed, whereas arrays in zsh are one-base-indexed.  So the
position of the cursor is after the 22 characters in the line, at
$BUFFER[23].  Even if you have the KSH_ARRAYS option set in the
interactive context to revert to zero-based arrays, completion uses
zsh default context with one-based arrays.

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
zsh-workers articles 31031 to 30137 but the wrong fix was done, it
changed the number of words examined (causing a different bug) rather
than remove the "1 +" offset calculation in the assignment to
COMP_POINT.  The new bug was noticed and reverted to the previous
behavior, which restored the original bug.

> When typing:
>
> ```sh
> $ scr a<tab>
> ```
>
> 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.

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.