Strange common prefix behavior: common suffix is included

[contentfree]

Environment

% typeset -p1 VENDOR OSTYPE ZSH_PATCHLEVEL _autocomplete__funcfiletrace
typeset VENDOR=apple
typeset OSTYPE=darwin21.0
typeset ZSH_PATCHLEVEL=zsh-5.8.1-0-g1a490c7
typeset -a _autocomplete__funcfiletrace=(
  /Users/davmyr/open_source/zsh-autocomplete/zsh-autocomplete.plugin.zsh:4
  /Users/davmyr/.zshrc:17
  zsh:19
)
% git -C ~autocomplete log --oneline -n1
e327674 (grafted, HEAD -> main, origin/main, origin/HEAD) Don't overwrite Autosuggest's default ignore list

• Operating system: macOS Monterey 12.6.5
• Terminal emulator: iTerm2 and Intellij terminal

Steps to reproduce

% cd $(mktemp -d)
% git clone --depth 1 -- https://github.com/marlonrichert/zsh-autocomplete.git
Cloning into 'zsh-autocomplete'...
remote: Enumerating objects: 55, done.
remote: Counting objects: 100% (55/55), done.
remote: Compressing objects: 100% (53/53), done.
remote: Total 55 (delta 0), reused 38 (delta 0), pack-reused 0
Receiving objects: 100% (55/55), 1.64 MiB | 5.16 MiB/s, done.
% > .zshrc <<EOF
setopt interactivecomments transientrprompt
PS1='%# '
PS2=
RPS2='%^'
zstyle ':autocomplete:tab:*' insert-unambiguous yes
source /var/folders/g5/k5pxm1j90md5q6d39v_qn0080000gp/T/tmp.UakSOtMY/zsh-autocomplete/zsh-autocomplete.plugin.zsh
EOF
% env -i HOME=$PWD PATH=$PATH TERM=$TERM ${TERMINFO:+TERMINFO=$TERMINFO} zsh -d
% touch up-dev.sh
% touch up-test.sh
% cat up
file
up-dev.sh   up-test.sh
common substring: up-.sh

Note the suggested common substring is not the common prefix but the entire string common to both. Hitting above inserts up-dev.sh and not up-. (And in my full normal zshrc profile, actually inserts up-.sh which is the genesis of this bug report.)

Contents of ~autocomplete-log/YYYY-MM-DD.log (click to expand)

(log file was empty… additionally, typing ~autocomplete shows two directories: autocomplete autocomplete-log and pushing did not insert the unambiguous part but instead completed to the first item autocomplete/ )

[contentfree]

I'm still trying to recreate the actual bug I'm witnessing in my normal zshrc where it's inserting up-.sh but the above does illustrate a similar issue where the unambiguous part is not inserted.

[marlonrichert]

First off, you're getting the zstyle selector wrong. Have another look at the documentation. The word tab shouldn't be in there.

Secondly, it doesn't say anywhere that only a common prefix would be inserted. Zsh's (somewhat awkwardly-named) "unambiguous" string is actually the you the longest possible string that, given the current matcher, unambiguously completes to all listed completions. Calling it the "common substring" is just my attempt at finding a better word for this.

So, not a bug. Working as expected.

[contentfree]

First off, you're getting the zstyle selector wrong. Have another look at the documentation. The word tab shouldn't be in there.

Ah, I got that from a comment you made in Discussions (https://github.com/marlonrichert/zsh-autocomplete/discussions/205#discussioncomment-451735) where you said:

What you want is: zstyle ':autocomplete:tab:*' insert-unambiguous yes

And as far as misinterpreting common string as common prefix, that was from bug Tab autocompletion picks first item instead of the longest common prefix and you seemed to be stating that their misconfiguration was the cause of the common prefix not being inserted. And not that the expectation that a common prefix would be inserted was wrong.

[contentfree]

Where would inserting the full common substring be useful? (Not disagreeing; curious.) Maybe when doing a copy or something and not navigation. Is it possible to change the behavior to only insert the common prefix when navigating?

[marlonrichert]

Ah, I got that from a comment you made in Discussions (https://github.com/marlonrichert/zsh-autocomplete/discussions/205#discussioncomment-451735) where you said:

That discussion is almost 3 years old. Things have changed. 🙂

Where would inserting the full common substring be useful?

I don't find it useful at all, but then again, I don't find inserting the common prefix useful either. 🤷🏽‍♂️

Anyway, if you want to change this behavior, then you need to customize the matcher-list setting. Adding an empty '' as the first item in the list might do the trick; not sure. In any case, I won't change this in Autocomplete's config.