Sven wrote:

> Felix wrote:
> > I think that would be ok.  Though it would also be nice to remove
> > some|all entries from the list being provided to the user.  Also,
> > it would be nice to provide help text for items.  I don't think
> > that can be currently done with the fake-* styles.
> 
> Erm, the ignored-matches style?

You mean ignored-patterns right?

> About the general fake style: I'm not sure where the compadd for it
> could be put. Probably in _setup or _description (where we have all
> the information about groups and so on), but there might be cases
> where the matches are then added more than once or into a group which
> isn't really used for matches (if the user doesn't give  near enogh
> context). Doing it with help texts further complicates this, of
> course. Especially if we want to have nice consistent listings
> because only the completion function decides if the normal matches
> get descriptions. We would just have to try it, I think.

I suggest we just try something and see how it goes. Locating it in
_description might work, assuming that the tag is in the context when
the style is looked up. It might be a bit strange where more than one
compadd is used to add matches.

> > I find that I want to use code
> > from the "state" actions of existing completion functions a lot.
> > It's not possible.
> 
> I've recommended that several times, although mostly because it makes
> writing functions easier (the main functions, using _arguments).

Yes, it is a good recommendation.

Patch to factor out a new _file_systems is below. The old _mount wasn't
even completing after umount -t so I'll apply this to 4.0 too.

> > >We should be careful how we document this. It should be a way of
> > >tweaking available completions to fake extra matches and should
not
> > >be a substitute for writing functions.
> > 
> > This is the sort of feedback I was interested in.  Though, it's not
> > clear to me why a completion function is better. 
> 
> My personal reason would be that I'd want to not fall into the
> compctl- trap again.

I'd agree with that reason.

> Yes, leaving the work for the users that have to set the styles (and
> if we are talking about those things I thik we are talking about,
> then there wouldn't be any defaults we could use for the styles). It
> might make sense to write some generic completer using lots of styles
> so that people have a way to `easily' create completions of their
> own, but I doubt it would be much easier than writing a little
> function, especially if the completion has to do anything useful. And
> how would that completer differ from _generic? Maybe we could just
> improve that one...

I'm not sure I like that much. We'd just end up with a style syntax for
_generic growing into a compctl like thing. And, we'd find ourself
having to graft much of this syntax onto every function.

Another method that might make things a little easier for user's unsure
about writing whole functions would be to allow simple one line
completions to be defined thusly:

compdef '_files -g "*.c"' lcc
compdef 'compadd one two three' count

It might be generally useful to allow arguments in the values of
_comps anyway.

Oliver

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com