Re: Default tags in _arguments and some more ...

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Andrej Borsenkow wrote:

> For file arguments - is it possible to specify default set of patterns
> that can be overridden using styles? More general - is there easy way to
> assign a tag inside _arguments description? What I mean, is something
> like
> 
> -I::compressed files:*.gz\:"compressed-files\:compressed-files"
> 
> with the effect, that tag name ``compressed-files'' with default pattern
> *.gz is used when completing argument of -I option.

This from the man who wanted a single tag for all files to specify
styles to be used whenever files are completed?

Currently _files can't be given pattern/tag/description arguments,
it's all (and only) under user control. I admit I though about it, but 
wasn't sure if it's worth it (implementation wouldn't be too
hard). The syntax would be something like `_files -p "*.gz:...:..."',
though. I didn't do it mainly because I wanted to keep the number of
tags used for files small.

> More general,
> something like
> 
> -F[file system type]::file system type:fsys-type(ufs vxfs)
> 
> that would use tag ``fsys-type'' when completing arguments of -F option.

Tags are really only specified by the final completion function. So,
_arguments could do it for the `(...)' actions, but otherwise...

Hm. I can see the sense in doing it for `(...)', but the syntax would
have to be something like `(...):tag'. But when the action is, e.g.,
one of our utility functions it would use the tags it always uses, so
the result might be a bit irritating, I think.

> As I understand, currently the latter is impossible (_inline_ - of
> course, using states everything is possible), and the former is limited
> to calling _files with patterns that will assign all patterns to
> globbed-files.
> 
> There are a couple more issues I do not much like
> 
> - special usage of blanks; it is way too easy to accidentally miss ot
> misplace them
> - very strict syntax for values. It is hard to add something new (as we
> have seen recently) and every new addition may be incompatible.

[ you mean actions ]

> So, here is suggestion that may be useful:
> 
> use flags to define semantic values. Something like
> 
> ...:::[l]foo bar baz    - for literal list of values
> ...:::[e]a shell string - for eval'ed string
> etc
> 
> This has a major advantage of being extensible without breaking existing
> usage. And we can easily define new flags like
> 
> ...:::[p]*.gz *.Z       - for file patterns; or even
> ...:::[p]*.gz:gzip-file *.Z:compressed-files - using the same syntax as
> for styles;

Argh. No special casing for files, please. If we start with that the
next thing would be a flag for parameters, one for command names, one
for... in other words: compctl.

> ...:::[t/weird-tag/]... - use tag `weird-tag' when completing these
> values

Well, some of this might be easy, but we would probably need help from 
C-code when the flag lists get more and more powerful. But thinking
about changing/checking every function that uses _arguments, _values
or _alternative gives me the creeps.

So, feel free to write that... ;-)  (I agree it looks nicer.)

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx