From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-7576-mason-zsh=primenet.com.au@sunsite.auc.dk>
Received: (qmail 25626 invoked from network); 31 Aug 1999 12:44:12 -0000
Received: from sunsite.auc.dk (130.225.51.30)
  by ns1.primenet.com.au with SMTP; 31 Aug 1999 12:44:12 -0000
Received: (qmail 29861 invoked by alias); 31 Aug 1999 12:43:59 -0000
Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm
Precedence: bulk
X-No-Archive: yes
X-Seq: 7576
Received: (qmail 29853 invoked from network); 31 Aug 1999 12:43:59 -0000
Date: Tue, 31 Aug 1999 14:38:58 +0200 (MET DST)
Message-Id: <199908311238.OAA29874@beta.informatik.hu-berlin.de>
From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
In-reply-to: Tanaka Akira's message of 31 Aug 1999 12:37:52 +0900
Subject: Re: 6-pws-2


Tanaka Akira wrote:

> In article <9908301600.AA12634@ibmth.df.unipi.it>,
>   Peter Stephenson <pws@ibmth.df.unipi.it> writes:
> > - Personally, I prefer one single completion function for a suite of
> >   related commands like cvs or pbm, since the accumulated clutter (and
> >   added time to process completion files the first time) is large.  If it
> >   stays the way it is I will change the default for function installation
> >   to keep the subdirectories.
> 
> The separation is sometimes useful for custumizations because we can
> override each function individually. These functions behaves like `hook'.
> I think it is useful that making hooks more easily without adding new files.

Hm. How about making it a bit like a state machine:

In functions like `_cvs' we make (some of) the actions look like
`state=command'. After return from `_arguments' we first look if
there is a user-supplied function, probably using a convenience
function like:

   call() {
    local ret
     if functions "$1" > /dev/null 2>&1; then
      "$1"
      ret=$?
      [[ $# -gt 1 ]] && eval "${2}=$ret"
      return 0
    fi
    return 1
  }

(Defined in `compinit' or in a file `_call' and probably with a better 
name, of course.)

So we would have:

  #compdef cvs

  local state ret

  _arguments ... '*::cvs command:state=command'

  call _cvs_$state ret && return ret

  case $state in
  ...
  command) ...
  esac

Depending on the complexity of the command we would probably have a
loop which steps through several states, probably calling `_arguments' 
again and so on.

If we want to be lazy we could also easily add a new action syntax
that stores a state name in a global (if not made local in a calling
function) parameter with a fixed name.

Would that be acceptable to everyone? Can anyone think of ways to help 
users write such state-machine functions?

Bye
 Sven


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