RE: Open bugs and questions?

[Sven Wischnowsky <wischnow@informatik.hu-berlin.de>]

Andrej Borsenkow wrote:

> Currently tags are used for two completely different tasks:
> 
> - as names for group of generated matches

I guess you mean `type' (at least that's what we called it in the docs ;-)

They are not used as `names for' what we call `groups'. Group names
are set with the group-name style. It's just that we offer a very
convenient way to name groups after the tags, so that all possible
groups have different names.

> - as special configuration parameters, used by some completion functions

Used to disambiguate between different meanings/uses of a style or to
simplify forming sensible context strings when defining styles.

I agree that this isn't very clean, but I don't have much problems
with it, actually. And it's documented (above the tag list).

> I never liked this; I believe, it originates in times when we did not have
> strict context names. Currently it is
> 
> - confusing.
> - limits configuration possibilities
> 
> What I mean under "limitations" - consider e.g. "hosts" tag. That is used for
> list of hostnames. But because it is tag, I can use it just once for a given
> context (a.k.a. command parameter). But I could quite sensibly wish two host
> sets - "trusted-hosts" and "untrusted-hosts" and complete them differently
> using two different lists. This is not (easy)possible now, unless I miss
> something.

If you can distinguish the elements of the two sets (and with a
complete list this is always possible), use tag labels.

Otherwise you want a way to influence how *often* the completion
functions generate matches and *which* matches on each try. Even that
is possible (either with tag labels or with completer-labels). But
styles weren't really thought to offer the possibilty to re-programme
completion functions. So, if you feel that you have to (or more)
completely different *types* of hosts (or whatever) -- copy and modify 
the functions completing hosts (or whatever). That's what they are for.

> Such tags simply do not fit into context idea because they represent static
> configuration parameter (valid gor completion function) rather then dynamic
> (valid for a given context).
> 
> Another example is:
> 
> bor@itsrm2% gdiff
> tags in context :completion::complete:gdiff::
>     argument-1 options  (_arguments _diff_options _diff)
> ags in context :completion::complete:gdiff:argument-1:
>     all-files  (_files _arguments _diff_options _diff)
> 
> Do we ever complete using tag argument-1? What I mean, is - it may be used
> internally by _arguments - but can user use it? Can it be used to set styles?
> As I understand, user sees context xxx:argument-1. I.e. in the above case we
> either complete tag "options" in context ":completion::complete:gdiff::" or
> tag "all-files" in context ":completion::complete:gdiff:argument-1:".

I agree that his isn't that nice and I wasn't too happy with it. But,
yes, they *are* used. And you can set styles for it and they will be
used, for example when the completion function uses an action of the
form `(a b c)'. In that case we don't have another way to get at a tag 
than by using the automatically created one.

> What I'd like to see is
> 
> - remove all "dummy" tags that are used only to look up styles

Eh? If they are used to look up styles, they are obviously used.

> - replace them with real per-context styles

I don't understand that, I think. Or do you mean that we should get
rid of the tags and rename the styles so that the style name itself is 
enough to disambiguate? And if you mean that: we already renamed
styles (twice, I think) to make this possible. So, if you know of any
styles we missed, tell us about them.

> - conssitently use "default" tag to setup default values for any context (I'd
> actually call it "-default-" to stress it's specialness).

Again: could you give us examples where you would want to set default
values for styles where you can't use `:completion:*' as the context
pattern?

> - do not list tags that may be used by completion system internally

Agreed, and I actually thought about this, too. By the fact that I
didn't send a patch you can see that I don't really know how to do
this (I haven't thought that much about it, though, having been busy
with a lot of other things at the time).

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de