Re: Questions (and PATCH: small change to _complete)

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Peter Stephenson wrote:

> ... [ making the command name distinguishable in context names ]
> 
> This looks OK, since (presumably?) it guarantees a special context after
> the name of the completer --- working well with the patch included in this
> post.  But for people to be sure they're matching the command name, they're
> going to have to do things like :*:*:dvips:* anyway, and presumably most
> people (probably including me) won't be that careful.  Still, it's
> definitely neater.

This `:*:*:dvips:*' is not guaranteed to work, because one can't be
sure how many components are before the command name. E.g. _complete
uses only :complete, but _approximate uses :approximate:<num-of-errors>
and both can be preceded by, e.g., :predict. Also, currently functions
may test for styles without appending a tag, so the trailing colon
wasn't guaranteed to work either. It is now, with the patch that made
the double colons be used.

> I see this has now become just `::', which is OK if it's going to be used a
> lot, something I can't really tell yet.  If it isn't, the full -argument-
> thing might be more consisent.

Yes, only time will tell. However, I've changed all the examples in
the docs (at least I hope I found all of them) and the _sort_tags
example function. So I hope people will do use that from the beginning.

> > Colours (in complist) for non-files (and grouping, you'll see):
> > 
> >   ZLS_COLOURS='**foo:[A-Z]*=47'
> 
> I'm so far a bit agnostic on this sort of thing.  How many people are going
> to go into this sort of detail to sort out groups and tags, whatever the
> syntax is?  Groups in particular are fairly well buried inside completion
> functions (unless something's changed here, I haven't completely absorbed
> everything about the latest status yet).  But I'm not against control of
> this kind.

Yes, currently, they are buried quite well. The question /behind/ the
grouping stuff I mentioned is: should we make them (more) visible? The
bit of discussion we had about the tag stuff (while you were away)
made me think that maybe we should make them visible and controllable.
But I'm far from certain if that wouldn't be too irritating to the
users. If we give control over it, I'd at least like to find a way so
that not using the mechanisms to control this stuff gives the current
behaviour as the default (probably the one without matches->group=yes, 
and then an easy way to specify exactly that behaviour with the new
mechanisms which should then be usable as a easy entry-example of how
one can control this stuff). That's also the reason why I keep trying
to connect this to tags (one-to-one correspondence between tags and
groups), because users can already see the tags and the way I tried to 
document that should make users think of tags as names of groups of
matches.

> ...
> 
> > Hidden matches in menu-selection:
> 
> Maybe they should behave like a special completion group, with a message
> above like `<Hidden Matches>', or something.  It makes it all explicit.

Ah. Hadn't thought of that. Sounds reasonable...

> > Tags and styles:
> > 
> > I've been asking for help for this several times already (I know that
> > you all need some more time to get used to all this new stuff, I only
> > want to put all my open questions here...). We might want to reduce
> > the number of tags used. For example, I think we could replace many of 
> > those currently used by `name' or `value'.
> 
> OK by me.
> 
> > And maybe some of the tag and style names can be changed to something
> > better?
> 
> We should make a complete list of the current ones (easy but dull) and see
> what it looks like, then maybe we'll get ideas.

The lists for tags and styles in the docs should be complete.

> > Then we still need a better name for `tag' itself.
> 
> The words which come to mind are horribly generic, like `type', or
> something involving `context' which will be ambiguous, even though it
> describes how tags are thrown up.  Unless someone has a brainwave, tag is
> at least (with our current language) reasonably unambiguous.

But it's also used for the #compdef- and #autoload-... err, well... -tags.

> ...
> 
> > Functions:
> > 
> > Before the next official release we might want to have a look if all
> > the completion functions are in the right directories. We've already
> > changed some (where it was obvious enough), but there may be more. And 
> > then there is the incompatibility problem Andrej somtimes remineded is 
> > of. Some functions may need tests on $OSTYPE or something. Oh, and I'd 
> > still like to have a _nis function to go along with _yp but still
> > don't have access to a NIS+ server. Sniff.
> 
> Needs checking, but can safely be left till fairly late, since it's
> maddening to have to do it over again after some tinkering.

Yep, that's what I meant, just before release.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx