Perplexing `COMP_POINT` value on bashcompinit tab completion (plaintext)

[Sav Erio <saverio.pub2@xxxxxxxxx>]

(I've previously sent this email from my email client, which sends in
HTML; this has apparently didn't work well with the mailing list
software, so I'm resending it from the Gmail web app, which should be
plaintext).

=====

Hello!

I use the OMZ/`bashcompinit` combination in order to write my tab
completion scripts.

The tab completion itself works, however, I'm writing more complex
scripts, and I find the `COMP_POINT` value perplexing, since it
doesn't match the intuitive value (the position of the cursor in the
string, which is what Bash returns).

Let's suppose you have a script named `/home/oooh_my_tab/scr`, whose
autocompletion is defined via `complete -C
"/path/to/myscript_completion" -o default scr`.

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

When typing:

```sh
$ scr a<tab>
```

Bash sends `COMP_LINE=scr a` and `COMP_POINT=5`, which, again, has
intuitive values.

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.

Is this a bug? Am I missing something? With such behavior,
`COMP_POINT` breaks compatibility with Bash tab completion scripts.

Thanks,
Saverio