From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16821 invoked from network); 29 Nov 1999 09:27:09 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 29 Nov 1999 09:27:09 -0000 Received: (qmail 11430 invoked by alias); 29 Nov 1999 09:27:04 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8797 Received: (qmail 11422 invoked from network); 29 Nov 1999 09:27:01 -0000 Date: Mon, 29 Nov 1999 10:27:01 +0100 (MET) Message-Id: <199911290927.KAA23203@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Peter Stephenson's message of Fri, 26 Nov 1999 22:08:12 +0000 Subject: Re: Questions (and PATCH: small change to _complete) 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: 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 `', 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@informatik.hu-berlin.de