Re: 6-pws-2

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Tanaka Akira wrote:

> In article <9908301600.AA12634@xxxxxxxxxxxxxxxxx>,
>   Peter Stephenson <pws@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx