Zsh Mailing List Archive
Messages sorted by:
RE: Open bugs and questions?
- X-seq: zsh-workers 12460
- From: Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxx
- Subject: RE: Open bugs and questions?
- Date: Tue, 1 Aug 2000 12:58:42 +0200 (MET DST)
- In-reply-to: "Andrej Borsenkow"'s message of Tue, 1 Aug 2000 13:46:04 +0400
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
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
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
> - 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).
Sven Wischnowsky wischnow@xxxxxxxxxxxxxxxxxxxxxxx
Messages sorted by: