Re: zstyle for _arguments feature request

["Wischnowsky, Sven" <Sven.Wischnowsky@xxxxxxxxxxxx>]

Felix wrote:

> Oliver Kiddle wrote:
> 
> >Yes, this could be useful. The form in which I'd like to see 
> it in is a
> >more general version of the fake-files and fake-parameters styles and
> >available in all contexts as opposed to just in _arguments.
> 
> 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? 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.

> ...
> 
> Yes, something like that could be done for this specific case.  Playing
> with the completion generation stuff, I find that I want to use code
> from the "state" actions of existing completion functions a lot.  It's
> not possible.  It seems that unless a state is very specific to a
> particular command, we should recommend people create new action
> functions over action states.

I've recommended that several times, although mostly because it makes
writing functions easier (the main functions, using _arguments).

> ...
> >
> >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've sort of thought
> that making a completer that got much of it's information via styles
> might be easy to create.

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...

> >>  * A completer for printf format strings using the "%" string.  I
> >>  think the real benefit would be the ability to see documentation for
> >>  the different format characters.
> >
> >Yes it would be useful but perhaps a little messy to implement. I
> >thought about doing printf completion for printf as opposed to find
> >which is less useful. I suspect that this might be a good place to use
> >_regex_arguments but I've yet to look in any detail.
> 
> I believe _regex_arguments is more for complex groups of flags/arguments
> not for dealing with completion within a string, but could be wrong.

Like most people I've never really taken the time look into _regex_arguments,
but I guess it's capable of doing this. Dunno if it would be easier (to write
and read) then writing some hand-crafted shell code for it. The C-code
contains the parsing code for this...

Bye
  Sven