Fwd: Perplexing `COMP_POINT` value on bashcompinit tab completion

Fwd: Perplexing `COMP_POINT` value on bashcompinit tab completion

[Geoff Wing]

[-- Attachment #1: Type: text/plain, Size: 13 bytes --]

HTML message

[-- Attachment #2: Type: message/rfc822, Size: 6049 bytes --]

[-- Attachment #2.1: Type: text/html, Size: 1864 bytes --]

From: "Saverio M." <saverio.pub2@gmail.com>
To: zsh-workers@zsh.org
Subject: Perplexing `COMP_POINT` value on bashcompinit tab completion
Date: Sat, 21 Jul 2018 11:31:02 +0200
Message-ID: <25ee6db0-9ef4-aa7c-e1eb-a7adfd590451@gmail.com>

Re: Perplexing `COMP_POINT` value on bashcompinit tab completion

[Bart Schaefer]

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.

Re: Perplexing `COMP_POINT` value on bashcompinit tab completion

[Oliver Kiddle]

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