PATCH: Re: rpm completion is unnecessarily slow and broken

PATCH: Re: rpm completion is unnecessarily slow and broken

[Sven Wischnowsky]

[moved to -workers, why was it on -users?]

Adam Spiers wrote:

> $ rpm -q --<TAB>
> 
> I think something must be going wrong with the matching, because not
> only does this run `rpm -qa' for some reason, but:
> 
> $ rpm -q --w<TAB>
> $ rpm -q --changelog
> zsh: do you wish to see all 61 possibilities (42 lines)?

A problem with the return value of _arguments when triggering a
->state action. The options were completed but the return value was
300 to indicate the ->state stuff.

This is ugly. For now I made _rpm check compstate[nmatches], but I
don't know if this is the right solution (and if it is, there may be
other functions where we should add it).

Maybe we should make _arguments return something different if options
were completed and calling functions should check that and decide
whether they want to try completion for the state at all and to get
their return value right. Suggestions, anyone?

Bye
 Sven

Index: Completion/Linux/_rpm
===================================================================
RCS file: /cvsroot/zsh/zsh/Completion/Linux/_rpm,v
retrieving revision 1.14
diff -u -r1.14 _rpm
--- Completion/Linux/_rpm	2000/06/05 23:20:48	1.14
+++ Completion/Linux/_rpm	2000/07/12 09:00:10
@@ -41,7 +41,7 @@
 
 # Used by `_arguments', made local here.
 
-local curcontext="$curcontext" state lstate line
+local curcontext="$curcontext" state lstate line nm="$compstate[nmatches]"
 typeset -A opt_args
 
 state=''
@@ -246,6 +246,8 @@
     _files "$expl[@]" -/ && ret=0
     ;;
   esac
+
+  [[ ret -eq 0 || $nm -ne $compstate[nmatches] ]] && return 0
 done
 
 return ret

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