Re: rsync --progress stops completion

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Sep 20,  3:20pm, Yuri D'Elia wrote:
}
} I'll take rsync as an example here.
} 
}   $ rsync --unknown
} 
} will stop the completion entirely. Surely, with _files you can go on,
} but I would like /--?.*/ to be simply treated as an unknown argument, so
} that a further flag would properly complete as expected as if --unknown
} was never there in the first place.

OK. so you'd like that.  That doesn't mean everyone would like that, so
you still haven't answered the question "how would you like to tell the
completion system about it, if not in the completer zstyle?"

On Sep 20,  3:25pm, Yuri D'Elia wrote:
}
} Also, to follow my previous discussion, I would somehow prefer a system
} where the completion *allows* unknown flags as a general rule for all
} completers.
} 
} I don't have enough knowledge of the existing completers to know though
} if this is feasible or not.

It's not particularly feasible because every completion function is just
that -- a shell function -- and there's no requirement that they be
implemented by passing through any single control point, except for
"compadd" by which time it is too late to affect the parse.  It might
be possible to add something to _arguments + comparguments to tell it
to ignore things it can't parse, but that still won't cover *every*
completion, and it would lead to false positives in cases where the
failure of one parse is followed by attempting a different one -- so
it would still have to be up to the individual completion functions to
"decide" whether to tell _arguments to do this.

However, perhaps the following is close enough to what you want?  This
is similar to doing "compset -n $CURRENT" except that it retains the
first word (presumably the command name).


_try_again() {
  [[ $compstate[context] = command && CURRENT -gt 2 ]] || return 1
  words=("$words[1]" "${(@)words[CURRENT,-1]}")
  CURRENT=2
  _compskip=default
  _normal -s
}
zstyle ':completion:*' completer _oldlist _expand _complete _try_again


Obviously this defeats any attempt at making option suggestions mutually
exclusive, and might (depending again upon the implementation of the
completion function) end up suggesting options where only a non-option
argument is valid.