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

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

[Sven Wischnowsky]

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@informatik.hu-berlin.de

Default tags in _arguments and some more ...

[Andrej Borsenkow]

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

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.

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;

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

-andrej

Have a nice DOS!
B >>