completion groups (was: Re: PATCH: _cd)

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

I wrote:

> Some time ago we had some people here asking if it were possible to
> see first only, say, `*.tar' files and then hit some to to get the
> directories. Now we have this discussion about showing options or
> not. Why not combine them? What I'm thinking about is a combination of 
> a completer that would be stuck in front of the `completer' key and
> uses some config keys and/or parameters/arrays/whatevers to set up
> some completion-system-global parameter(s). These are then used by all 
> completion functions concerned to find out which matches should be
> generated (and how, thinking about descriptions). And with (an
> improved (and renamed) version of) `_verbose_list' one could get this
> `first-this-and-then-that' behaviour.

I've thought some more about this over the weekend (trying to avoid
hacking the nested-braces and the nested-quotes problem which look
more and more complicated...).

I think I'd like to make this an integral part of the completion
system (no extra completer function). It would go like this:

We have a helper function, say `requested' which gets one (but see
below) argument, a `tag'. This function uses some keys or (probably
needed) parameters (arrays) that describe what kind of matches the
user wants to have generated. This description may be a list of tags
and if the tag given as argument is in that list, `requested' returns
zero, non-zero otherwise. The description may also be a number, so
that if it is `1', `_requested' return only zero the first time it is
called, if it is `2' the second time and so on. It should be possible
to specify the tag-lists in a way depending on: the command on the
line, the word on the line (so that we could get the `option_prefix'
behaviour with this mechanism, too), and, maybe, even based on some
other information which may be given as argument to `_requested'. What 
I'm thinking about here is `_files': it could give the `-g' pattern it 
gets to `_requested' and one could then specify that one wants to see
directories immediatly whenever a tar-file is completed, but not if a
executable is completed (stupid example, but I hope you understand
what I mean).

Anyway, with that every well-behaved completion function (especially
those that add different types of matches) would do something like:

  if _requested foo; then
    ...
  fi

The `_files' example that brought all this up is a bit of a special
case. We could either use the syntax Peter suggested to make it try
different file types, each with a call to `_requested' or we could add 
an option which says `also complete directories if the user wants to
see them immediatly'. Or we could make `_files' always do that unless
some new option is given.

The `_requested' function would also store the tags given by all calls 
to it and all tags for which zero/non-zero was returned in arrays so
that other functions could have a look at this.

One function (or a set of functions) using this would be the
replacement for `_verbose_list' giving much more detailed control over
what should be listed or what should be completed next. We could have
commands to cycle through the different tag-groups, commands to
temporarily augment the list of tags to use, heck, we could even have
a command that first runs completion to only get the tags, offers
these to the user and lets him select those he wants to see (although
that would give a style of completion I certainly couldn't get used to 
;-).

The biggest problem I see with this (and for which I don't have a good 
solution yet) is how we choose the tags. If every function that adds
different types of matches uses tags roughly describing the type this
would obviously result in a plethora of tags and users would have to
keep monstrous lists of tags they want to see. We could allow
descriptions like `everything except...' (this would probably be
useful to have anyway). Or we could have a set of standard names (like 
normal/alternate, primary/secondary, ...). This could be combined with
making `_requested' accept multiple tags as arguments so that a
function like `_kill' would use `_requested normal jobs' and
`_requested alternate pids'. But all this isn't really satisfying, I
think, because then the user would still sometimes get matches he
doesn't want to see on the first completion attempt just because some
functions use the same tag. And depending on the way we want to look
at it, this is probably even a bit more complicated if we think about
things like options and their descriptions (this is not only
constrained to options and values if we want let users say if they
want to see the long displays we use the `-d' option for or not). Here 
we really have some kind of sub-tag (`options' versus `options-with-
descriptions').


Ok, what do you think. Is any of this interesting enough for enough
people to work on or have I just gone mad (or both?). For those who
like this: any suggestions for the tags-problem or comments or
whatever?


Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx