* Fwd: Perplexing `COMP_POINT` value on bashcompinit tab completion @ 2018-07-21 11:15 Geoff Wing 2018-07-22 0:27 ` Bart Schaefer 0 siblings, 1 reply; 3+ messages in thread From: Geoff Wing @ 2018-07-21 11:15 UTC (permalink / raw) To: zsh-workers [-- 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> ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Perplexing `COMP_POINT` value on bashcompinit tab completion 2018-07-21 11:15 Fwd: Perplexing `COMP_POINT` value on bashcompinit tab completion Geoff Wing @ 2018-07-22 0:27 ` Bart Schaefer 2018-07-22 22:14 ` Oliver Kiddle 0 siblings, 1 reply; 3+ messages in thread From: Bart Schaefer @ 2018-07-22 0:27 UTC (permalink / raw) To: zsh-workers; +Cc: Saverio M. 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. ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Perplexing `COMP_POINT` value on bashcompinit tab completion 2018-07-22 0:27 ` Bart Schaefer @ 2018-07-22 22:14 ` Oliver Kiddle 0 siblings, 0 replies; 3+ messages in thread From: Oliver Kiddle @ 2018-07-22 22:14 UTC (permalink / raw) To: zsh-workers, Saverio M. 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2018-07-22 22:21 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-07-21 11:15 Fwd: Perplexing `COMP_POINT` value on bashcompinit tab completion Geoff Wing 2018-07-22 0:27 ` Bart Schaefer 2018-07-22 22:14 ` Oliver Kiddle
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).