Thanks for your comments. :)

Attached is a new version of the patch, which should address most of
your points and also corrects some false assumptions I had about the
matching logic. Below are my replies to points not addressed by the
patch.


On Wed, Oct 13, 2021 at 7:57 AM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> For example, this part is misleading:
>
> > > +By default, characters in the string to be completed (referred to here as the
> > > +command line) map only onto identical characters in the list of matches
> [...]
> > > +missing characters are inserted only at the cursor position, if the shell
> > > +option tt(COMPLETE_IN_WORD) is set, or at the end of the command line,
>
> It's at the end of the current word, not the end of the command line.
> The old wording nearly always says "string on the command line" which
> is only somewhat better; if it's going to be completely rewritten to
> drop "string on the", the phrase "command line" should become more
> precise.  "Incomplete word" perhaps?

On Thu, Oct 14, 2021 at 11:43 PM Oliver Kiddle <opk@zsh.org> wrote:
>
> Is "trial completions" the best term we can come up with? Where it
> occurs in singular form it isn't obvious that it doesn't refer to what
> is on the command-line. I tend use "candidate matches". With the term
> "matches" for those that remain following matching. Or does anyone have
> other ideas?

I iterations over several permutations of terms in the docs and found
that this one seems to work best:

"When the user invokes completion, the _current word_ on the command
line is used to generate a _match pattern_ defining which
_completions_ are considered _matches._"

This also matches the use of these terms in the majority of the
manual. Where it doesn't match in compwid.yo, I've changed the text so
that it does.


On Thu, Oct 14, 2021 at 11:43 PM Oliver Kiddle <opk@zsh.org> wrote:
>
> "completions" is already rather overloaded because it is
> also used for completion definitions for commands.

I used "completions" anyway, because it feels like the most natural
and concise word to use for this purpose. It doesn't appear to cause
any ambiguities in the text.


On Fri, Oct 22, 2021 at 4:02 PM Oliver Kiddle <opk@zsh.org> wrote:
>
> > --- a/Test/Y02compmatch.ztst
> > +++ b/Test/Y02compmatch.ztst
>
> > - comptest $'tst c...pag\t'
> > -0:Documentation example using input c...pag\t
> > + comptest $'tst ...pag\t'
> > +0:Documentation example using input ...pag
>
> It is good to have tests matching exactly the examples in the documentation but
> in some cases there could be value in preserving the essence of the old test
> too. To get good test coverage, we want empty and partial components in both
> the middle and beginning of the command line to be tested.

I'm not sure what these tests should look like. So, I didn't add them.


On Fri, Oct 22, 2021 at 4:02 PM Oliver Kiddle <opk@zsh.org> wrote:
>
> > + example5b_matcher='r:[^.,_-]||[.,_-]=* r:|=*'
> > + test_code $example5b_matcher example5_list
> > + comptest $'tst  .c\t^[bv\t.h\t^[bv'
> > +0f:Documentation example using input .c but with double anchor
>
> The second tab doesn't really test the matcher because the cursor is located
> where characters need to be added.

On Thu, Oct 14, 2021 at 11:43 PM Oliver Kiddle <opk@zsh.org> wrote:
>
> I'm fairly sure that if complete_in_word is unset, missing characters
> are still allowed at the cursor position.

No, it does not appear to work like that in vanilla zsh:

% PS1='%# ' zsh -f
% autoload compinit; compinit
% _tst() { compadd veryverylongfile.c }
% tst v.c^B^B\t

The word 'v.c' in this example will not get completed, no matter where
you put the cursor.