Re: Bug#236350: zsh: _prefix completer broken?

Re: Bug#236350: zsh: _prefix completer broken?

[Clint Adams]

>     zstyle ':completion:*' completer _complete _prefix
> 
> However, it doesn't seem that _prefix is having any effect.  According
> to everything I've read, I should be able to type "vfoo", put the cursor
> over the 'f', hit tab, and get offered completions like "vi", etc.
> Instead, I just get a beep.

If you setopt COMPLETE_IN_WORD, it will complete vi, but otherwise, it
doesn't appear that $SUFFIX is being set.

Re: Bug#236350: zsh: _prefix completer broken?

[Andrew Pimlott]

On Fri, Mar 05, 2004 at 08:35:13PM -0500, Clint Adams wrote:
> >     zstyle ':completion:*' completer _complete _prefix
> > 
> > However, it doesn't seem that _prefix is having any effect.  According
> > to everything I've read, I should be able to type "vfoo", put the cursor
> > over the 'f', hit tab, and get offered completions like "vi", etc.
> > Instead, I just get a beep.
> 
> If you setopt COMPLETE_IN_WORD, it will complete vi, but otherwise, it
> doesn't appear that $SUFFIX is being set.

I really don't know how I missed that in the documentation and all the
searches I did, but when I setopt COMPLETE_IN_WORD, it indeed does work.
I guess the bug is only that compinstall doesn't generate a complete
configuration for _prefix.  It would probably also be useful to move the
mention of COMPLETE_IN_WORD higher in the documentation for _complete,
and include it in the examples.

I noticed a couple other things.  The documentation says that the
add-space style defaults to true.  This doesn't seem to be the case, as
if I complete with the cursor on 'f' in "egrefoo", I get just "p" by
default, and "p " with

    zstyle ':completion:*' completer _complete _prefix

in my config.

Also, when the completion on prefix succeeds, as in the "egrefoo"
example, there is a beep, unlike with a normal successful completion.
This is distracting.

Thanks for your help.

Andrew

Re: Bug#236350: zsh: _prefix completer broken?

[Bart Schaefer]

On Mar 6, 11:05am, Andrew Pimlott wrote:
} Subject: Re: Bug#236350: zsh: _prefix completer broken?
}
} I noticed a couple other things.  The documentation says that the
} add-space style defaults to true.  This doesn't seem to be the case, as
} if I complete with the cursor on 'f' in "egrefoo", I get just "p" by
} default, and "p " with
} 
}     zstyle ':completion:*' completer _complete _prefix
} 
} in my config.

The add-space style does default to true, and you're seeing exactly what
you should be seeing.  What you (and possibly the documentation) missed
is that the add-space style applies only to the _expand and _prefix
completers, so its default setting makes no difference if you aren't
using one of those.
 
} Also, when the completion on prefix succeeds, as in the "egrefoo"
} example, there is a beep, unlike with a normal successful completion.

This I can reproduce with 4.0.7.  However, I'm having some trouble getting
_any_ of this to work with 4.2.0-pre-3.  Sample output:

schaefer<504> egrefoo
No matches for `external command', `builtin command', `shell function',
`alias', `suffix alias', `reserved word', `job', `parameter', `local
directory', `directory in cdpath', or `corrections'

Here's 4.0.7 for comparison:

schaefer[538] egrefoo
schaefer[538] egrepfoo

(with a feep)

(Aside - in 4.0.7 if I then go on and hit TAB again I get this:

schaefer[538] egrepfoo
                   _
Completing external command

(with the underscore showing the location of the cursor).)

In both 4.2.0-pre-3 and 4.0.7, my completion style looks like this:

zstyle ':completion:*' completer \
  _oldlist _expand _complete _match _ignored _approximate _prefix

However, 4.2.0-pre-3 never gets beyond trying _approximate.  The output
from complete-debug is nearly a megabyte, but it looks as if it gets to
this point in both versions:

: _approximate:75:while; [[ _comp_correct -le comax ]]
: _approximate:111; compstate[pattern_match]='' 
: _approximate:113; return 1
: _main_complete:1; unfunction compadd

And then 4.2.0-pre-3 goes on like this:

: _main_complete:159:for for elif-then; ret=0 
: _main_complete:160:for for elif-then; break 2  <-- doesn't happen in 4.0.7
: _main_complete:169; curcontext=::: 
: _main_complete:170; nm=0 

Re: Bug#236350: zsh: _prefix completer broken?

[Bart Schaefer]

On Mar 6,  5:38pm, Bart Schaefer wrote:
} Subject: Re: Bug#236350: zsh: _prefix completer broken?
}
} schaefer<504> egrefoo
} No matches for `external command', `builtin command', `shell function',
} `alias', `suffix alias', `reserved word', `job', `parameter', `local
} directory', `directory in cdpath', or `corrections'
} 
} : _main_complete:159:for for elif-then; ret=0 
} : _main_complete:160:for for elif-then; break 2  <-- doesn't happen in 4.0.7
} : _main_complete:169; curcontext=::: 
} : _main_complete:170; nm=0 

This looks like it could be a serious problem.  The code in question is
this:

    if [[ -n "$call" ]]; then
      if "${(@)argv[3,-1]}"; then
        ret=0
        break 2
      fi
    elif "$tmp"; then
      ret=0
      break 2
    fi

_approximate is being called as "$tmp" here.  It returns 1, but the
test succeeds and breaks out of the loop, because _approximate uses
"trap 'unfunction compadd' EXIT INT" and the return code of the trap
is being propagated rather than the return code of _approximate.

Re: Bug#236350: zsh: _prefix completer broken?

[Oliver Kiddle]

Bart wrote:
> 
> The add-space style does default to true, and you're seeing exactly what
> you should be seeing.  What you (and possibly the documentation) missed
> is that the add-space style applies only to the _expand and _prefix
> completers, so its default setting makes no difference if you aren't
> using one of those.

I can reproduce:
% zsh -f
% autoload -U compinit; compinit
% setopt completeinword
% zstyle ':completion:*' completer _complete _prefix
% egre<tab>foo
 gives:
% egrepfoo
  with the cursor over the f.

So where's the space?
Now set: zstyle ':completion:*' add-space true
and try again. Is it perhaps just meant to be for _expand that
add-space defaults to true?

> In both 4.2.0-pre-3 and 4.0.7, my completion style looks like this:
> 
> zstyle ':completion:*' completer \
>   _oldlist _expand _complete _match _ignored _approximate _prefix
> 
> However, 4.2.0-pre-3 never gets beyond trying _approximate.  The output

This is the bug I reported in 17846.

For now, I moved _prefix before _approximate.

Oliver

Re: Bug#236350: zsh: _prefix completer broken?

[Bart Schaefer]

On Mar 6,  7:03pm, Oliver Kiddle wrote:
} Subject: Re: Bug#236350: zsh: _prefix completer broken?
}
} > zstyle ':completion:*' completer \
} >   _oldlist _expand _complete _match _ignored _approximate _prefix
} > 
} > However, 4.2.0-pre-3 never gets beyond trying _approximate.
} 
} This is the bug I reported in 17846.

Aha.

} For now, I moved _prefix before _approximate.

I still think the trap behavior is wrong, but as a stopgap we can do this:

Index: Completion/Base/Completer/_approximate
===================================================================
--- _approximate	7 Jan 2002 15:18:19 -0000	1.5
+++ _approximate	6 Mar 2004 23:26:05 -0000
@@ -65,7 +65,7 @@
 
     builtin compadd "$_correct_expl[@]" "$@"
   }
-  trap 'unfunction compadd' EXIT INT
+  trap 'local _x=$?; unfunction compadd; ((! $_x))' EXIT INT
 fi
 
 _comp_correct=1

This won't work in general because (( )) can only return 1 or 0, not
some arbitrary exit code, but it's fine for _approximate.

Re: Bug#236350: zsh: _prefix completer broken?

[Peter Stephenson]

Oliver Kiddle wrote:
> > zstyle ':completion:*' completer \
> >   _oldlist _expand _complete _match _ignored _approximate _prefix
> > 
> > However, 4.2.0-pre-3 never gets beyond trying _approximate.  The output
> 
> This is the bug I reported in 17846.
> 
> For now, I moved _prefix before _approximate.

I haven't looked at the cause again, but in my reply dated 28th October
2002 I said `Perhaps there's an obvious answer but I can't see it at
the moment'.

So if you want this to work, it looks like you will need to change the
completion code.

Year-long delays of this kind are inevitable when there are so few of us
working on the internals.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************