Re: Fun with new completion

Re: Fun with new completion

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> bor@itsrm2:~%> vared pat
> pat    path
> 
> In other words, vared tried to complete the name of local variable, that is
> defined in completion function :-) pat is not defined otherwise.
> 
> And it just occured to me, that the same could happen in e.g. [un]setopt. As
> I understand, they do it by listing currently set/unset options ... with the
> result, that if options are changed in some top level function, they will
> list wrong options ...

I was aware of the problem with parameter names, but hadn't thought
about the options.

Maybe we should rename the local parameters (where needed) to `_...',
modify the function `_vars' to show  only parameters without a leading 
underscore and be callable from everywhere.
For the options I can only see the solution to make `_main_complete'
save the original set and unset options in arrays and then add two
functions to complete from these arrays (this is currently only used
for `setopt' and `unsetopt', but to make this cleanly...).

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

RE: Fun with new completion

[Andrej Borsenkow]

>
> Maybe we should rename the local parameters (where needed) to `_...',
> modify the function `_vars' to show  only parameters without a leading
> underscore and be callable from everywhere.

I would not rely on names (it is good as convention - but imagine bug
reports "ZSH does not complete my variables" :-)

What about adding GLOBAL flag to variables and option to list only
global/local ones? Sounds nice (and may be useful in other contexts as well)

cheers

/andrej

Fun with new completion

[Andrej Borsenkow]

bor@itsrm2:~%> vared pat
pat    path

In other words, vared tried to complete the name of local variable, that is
defined in completion function :-) pat is not defined otherwise.

And it just occured to me, that the same could happen in e.g. [un]setopt. As
I understand, they do it by listing currently set/unset options ... with the
result, that if options are changed in some top level function, they will
list wrong options ...

/andrej

Re: Fun with new completion

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> I have /archive/pub/unix/sudo/ with cu-sudo* files in it. I forgot, that
> they are prefixed with cu- and did
> 
> gzcat /a/p/u/s/s<TAB>
> 
> with the nice result
> 
> gzcat //a
> 
> Plain old multicomp just beeps and leaves the string as is. Now, it is
> _really_ hard to decide what to do ... Should it complete as far as
> possible? Or, if nothing matches, leave command line as is? Again, the
> problem is, zsh cannot read your mind and decide, where was the error.

At least it shouldn't give what it gives now... this was something
that looked good for the things I tried it with but sometimes...

The patch below makes it leave the line unchanged. A probably better
solution would have a second loop over the `-W' paths to try to expand 
as much of the path as possible. Hm, I /think/ that would be better...

Bye
 Sven

P.S.: The senders in the summary of my mail reader look like a party
      of ping-pong between Andrej and me...

diff -u oc/Core/_path_files Completion/Core/_path_files
--- oc/Core/_path_files	Tue Mar  9 15:31:15 1999
+++ Completion/Core/_path_files	Tue Mar  9 15:46:06 1999
@@ -261,9 +261,6 @@
       # next `-W' path.
 
       if [[ $#collect -eq 0 ]]; then
-        compadd -QU "$addpfx[@]" "$addsfx[@]" "$group[@]" "$expl[@]" \
-                -i "$IPREFIX" -p "${linepath:q}${testpath:q}" -S "/${ostr#*/}" \
-		-W "$tmp1" -f "$ignore[@]" - "${(@)tmp1:q}"
         continue 2
       elif [[ $#collect -ne 1 ]]; then
         # If we have more than one possible match, this means that the

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Fun with new completion

[Andrej Borsenkow]

I have /archive/pub/unix/sudo/ with cu-sudo* files in it. I forgot, that
they are prefixed with cu- and did

gzcat /a/p/u/s/s<TAB>

with the nice result

gzcat //a

Plain old multicomp just beeps and leaves the string as is. Now, it is
_really_ hard to decide what to do ... Should it complete as far as
possible? Or, if nothing matches, leave command line as is? Again, the
problem is, zsh cannot read your mind and decide, where was the error.

cheers

/andrej