From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1920 invoked from network); 7 Apr 2000 07:41:46 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 7 Apr 2000 07:41:46 -0000 Received: (qmail 11977 invoked by alias); 7 Apr 2000 07:40:48 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 10569 Received: (qmail 11887 invoked from network); 7 Apr 2000 07:40:42 -0000 Date: Fri, 7 Apr 2000 09:40:37 +0200 (MET DST) Message-Id: <200004070740.JAA23635@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Peter Stephenson's message of Thu, 06 Apr 2000 19:52:10 +0100 Subject: Re: PATCH: Re: Tags again Peter Stephenson wrote: > Sven Wischnowsky wrote: > > The manual says that the tags are tried `one after another'. I.e. it > > first offers globbed-files, if that fails directories, etc. It does > > *not* offer them all at once. > > Eh? > tag-order Erm... the description for the file-patterns style says what I quoted. > ... > > Are you saying this doesn't apply to files? Or that ordering in > file-patterns takes precedence? Or that it's not supposed to work any more > (and if so, how do I get tags from other sources offered at the same time, > and why does it appear to be happening with all the various things in > command position)? Ok, I'll give you the longer story now... _files (which, as you know, does the file-patterns stuff including the default globbed-files/directories/all-files, which is now only the default for the file-patterns style) *is* different from other completion functions with respect to the tags it offers. And it always was. The difference is that, e.g. _command_names offers all its tags at once because that makes sense -- you (may) want it to complete all the different things when you try completion in command position and you want them now and the matches in the groups are nicely separated, there is no overlap (ok, names may appear in more than one group, but they still are different matches). In _files, however, the tags represent different sub-sets of one type of matches. You don't want to try *all* of them immediatly because that would always give all-files. Before my last changes to _files (at the time labels/aliases were implemented), _tags had to use globbed-files, directories and all-files in the default for the tag-order style. It *had* to use it to ensure the first-globbed, then-dirs, then-all behaviour. With the then-fixed set of tags offered by _files this was possible, but when tags named by users (both in tag-order and in file-patterns) became reality, this wasn't possible any more. At least not cleanly and because of that I changed it in 10267. Before 10267 _tags checked if the tags came from _files. If not, they were (as the usual default behaviour) added to be tried in one go. But if they came from _files, the default behaviour was to make them be tried one after another. Very ugly, as I hope you agree. So 10267 made _files call _tags for each tag. One could still use tag-order but there aren't many possibilities to order the one tag offered, so... However, one could still use it with labels, of course. One nice effect of this change is that we don't need any of the file-tags in the default value of tag-order because, as users see it, the file-patterns style -- including the default value for it -- already does the ordering. Ok. The problem that finally made me implement 10267 wasn't the ugliness in _tags, the for most callers add them together, but for files add them separately thing. The real problem was the combination with the possibilities of using patterns in tag-order. Consider the settings for trying completion without a matcher and then trying it with case-insensitive completion, defined for a specific enough context so that you have to use the matcher style: zstyle ':completion:...' tag-order '*' '*:-case' zstyle ':completion:*:*-case' matcher 'm:{a-z}={A-Z}' Quite simple and relies heavily on patterns, but by using them this can be used in every context. And now think about what would happen if _files would offer all tags in one go. You would end up with all-files, all-files-case behaviour (`behaviour', internally it would even try globbed-files, directories and all-files, calling _path_files three times, where the last call generates all the matches added by the first two calls). But by making _files try the tags one after another, you get the behaviour you want. If not you can still use the real tag names in tag-order to form the labels you want. So here is one reason for your next question: > And if tag-order isn't useful with files, what's the > point of having to name the tags (which until a few hours ago was > compulsory)? And the second answer: tags are not only used in tag-order as you well know. They are (probably more importantly) used for lookup, so allowing file-patterns to specify tags, users have the possibility to set all the other styles that are tested for tags for the different types of files. Maybe they want to use different patterns to ignore for normal files and for directories. Or different matchers, description-formats, whatever. If file-patterns wouldn't allow to specify tags, all this wouldn't be possible. Ok. Any questions left? ;-) Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de