Thanks for your help with this Bart!

When I leave completeinword unset, _prefix completion simply doesn't work,
even if I have:

zstyle ':completion:*' completer _expand _prefix _complete _ignored _prefix

Or if I have:

zstyle ':completion:*' completer _expand _prefix _complete _ignored

(I also don't have alwaystoend set.)

One additional thing I've found to be really strange about _prefix
completion is if there is only one possible match. For example:

% ls -a
./  ../
% mkdir -p dir1/dir2/dir3
% ls dir1/di_r2/dir3<menu-complete>   (<-- where _ is the position of the
cursor)
% ls dir1_   (<-- the "/dir2/dir3" part of the line has been removed!)
% ls dir1/dir2/di_r3<menu-complete>   (<-- where _ is the position of the
cursor)
% ls dir1_   (<-- same thing happens)
% ls di_r1/dir2/dir3<menu-complete>   (<-- where _ is the position of the
cursor)
% ls dir1_r1   (<-- where _ is the position of the cursor. The suffix only
until the first slash, "r1", has been kept after the cursor, but the
"/dir2/dir3" part of the suffix has been removed!)

When there are more than one possible completions, this doesn't happen and
_prefix completion works normally by the previously stated behavior (i.e.
keeps the entire suffix after the cursor, but completes/cycles only on the
prefix).

Seems like when there is only one possible match, the definition of prefix
and suffix gets thrown out the window... possibly a bug?

On Sat, Jun 13, 2020 at 11:07 PM Bart Schaefer <schaefer@brasslantern.com>
wrote:

> On Wed, Jun 10, 2020 at 8:26 PM Alan <8fvebtoeq87@gmail.com> wrote:
> >
> > Yes, I've tried *not* setting the complete_in_word option, but then the
> _prefix completer doesn't work. See this (rather bizarre in my opinion)
> explanation from http://zsh.sourceforge.net/Guide/zshguide06.html:
> >
> > "One gotcha with the _prefix completer: you have to make sure the option
> COMPLETE_IN_WORD is set. That may sound counter-intuitive: after all,
> _prefix forces completion not to complete inside a word. The point is that
> without that option, completion is only ever tried at the end of the word,
> so when you type <TAB> in the middle of <prefix><suffix>, the cursor is
> moved to after the end of the suffix before the completion system has a
> chance to see what's there, and hence the whole thing is regarded as a
> prefix, with no suffix."
>
> As you've noticed, I think this advice only applies when _prefix is
> attempted after _complete, or possibly when the ALWAYS_TO_END option
> is set (which by default it is not).  I don't think COMPLETE_IN_WORD
> is relevant unless you want prefixes completed only when no other
> possibility is found (which is probably what it was thought most
> people would expect).
>
> If someone has a chance to test a few combinations and update that
> doc, please go ahead.  I might but I don't know how soon.
>
> > (I'm not actually entirely clear how the completer ordering works, so
> not sure if I need that second _prefix instance at the end, but whatever
> works I guess. If someone would care to shed some light on the matter, that
> would be good too.)
>
> The completion process happens in a nested loop:  For each function in
> the completer list, try it with each of the patterns in the
> matcher-list.  Ordinarily this loop stops as soon as one of the
> completers returns zero (true), which is why the order is important,
> but the _all_matches completer can change that.
>
> The only reason to put _prefix in the list twice would be to implement
> the example of doing so that appears in the documentation for _prefix.
>