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
Attachment:
fs.dif
Description: fs.dif