From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19673 invoked from network); 17 Mar 2000 18:22:28 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 17 Mar 2000 18:22:28 -0000 Received: (qmail 6226 invoked by alias); 17 Mar 2000 18:22:22 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 10164 Received: (qmail 6201 invoked from network); 17 Mar 2000 18:22:20 -0000 From: "Bart Schaefer" Message-Id: <1000317182054.ZM28046@candle.brasslantern.com> Date: Fri, 17 Mar 2000 18:20:54 +0000 In-Reply-To: <200003141419.PAA05010@beta.informatik.hu-berlin.de> Comments: In reply to Sven Wischnowsky "tags and all that..." (Mar 14, 3:19pm) References: <200003141419.PAA05010@beta.informatik.hu-berlin.de> <200003170905.KAA01669@beta.informatik.hu-berlin.de> In-Reply-To: <200003170905.KAA01669@beta.informatik.hu-berlin.de> Comments: In reply to Sven Wischnowsky "Re: ignored-patterns giving correction a go" (Mar 17, 10:05am) X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-workers@sunsite.auc.dk Subject: Re: ignored-patterns giving correction a go MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Mar 17, 10:05am, Sven Wischnowsky wrote: } Subject: Re: ignored-patterns giving correction a go } } I use something like: } } zstyle :completion::::: completer _next_tags _expand _complete \ } _complete _match _correct \ } _approximate _prefix BTW, there's no doc for _next_tags ... what happens if you invoke it as a widget but it's NOT in your completer list? } zstyle ':completion:*:complete-2:*' prefer-ignored yes } zstyle ':completion:*:(correct|approximate|prefix)-1:*' prefer-ignored yes Obviously the documentation for using a completer twice doesn't belong just under the matcher-list spec any more. } All this alternate-set stuff looks like a hack. [...] The problem is } that if we remove the alternate set stuff for new completion, we'll } have trouble re-implementing the behaviour of $fignore, at least when } we want it to have the exact same effect. The tricky bit is really the fail-over behavior, isn't it? That is, the way the alternate set is automatically used if the "real" set is empty? So what if we just made the alternate set a group of its own, on the same level as the -default- group, e.g. -alternate-. Change the -a option of compadd to require an argument, `-a alternate-group-name', that, when used with `-[JV] group-name' and `-F array' names the group into which the completions matching the -F patterns are placed; the sorting of that group is the same as for the -[JV], -[12] apply, etc. When no -a is given the -alternate- group is used by -F, and when -a is given with no -[JV], the completions that don't match the -F pattern go into -default-. (I'd almost rather pick a different option that -a and eliminate -a entirely, to break noisily any completion functions that now use -a without an argument; but -A is already taken, as are most of the other sensible letters.) Then make the default completion behavior be as if the tag-order were the array (-default- -alternate-). If in any context the tag-order style is overridden, the user must explicitly name -alternate- (or any group passed with -a by other completion functions) to have it used. Document this, of course. For the special case of fignore, _files and _path_files can use -a to name multiple alternate group names, and play with the default tag-order the way _files already does for globbed-files directories all-files. Does that sound like it'll (1) work and (2) be less of a hack than the present behavior? An advantage is that you can cause alternates from several groups to accumulate all in the same place, so for _files you might have the groups globbed-files directories all-ignored-files all-files, where all-ignored-files includes both files and paths that matched $fignore. Not that this is how I'm suggesting it work, I'm just using it by way of example. One problem is that I don't see how you can eliminate the current alternate-set support from the C code and still have fignore work for old compctl, but maybe you have an idea for going about that. Or maybe that code would just go unused in the new system. (What happens right now if you call compadd -V group ... and later compadd -J group ... that is, specify some sorted and some unsorted matches for the same group?) (What's the point of setting groups[2] inside the _tags loop in _files? it doesn't appear to get used anywhere after line 19 where it's copied into the opts array.) } Some more about 10134: after having thought about it some more, I } begin to like the suggestion with `tag-order tag=method ...' with the } shortcut `tag-order foo'. The only issue I have with this is that it increases the number of similar zstyle commands one must give to configure a behavior. Here's your example from 10134: } zstyle ... tag-order foo=files bar=files } zstyle '...:foo' file-patterns '*.ps' Presumably the '...' part in both of those lines is, in many cases, going to be the same. And then you need to repeat it _again_ to give the patterns for `bar'. I find myself wishing for some way to merge them, maybe something like zstyle ... tag-order foo=files bar=files \ + foo file-patterns '*.ps' \ + bar file-patterns '*.pdf' That specific example would make the word `+' magic, which might not be a good idea ... but we're running out of metacharacters that don't need to be annoyingly quoted. I was going to try to reply in some detail to 10134, but I'm out of time and (other than preferring the tag=method form to having yet _another_ set of styles to name method-tags) it's probably better if Sven just tries things out and reports how well he thinks they work. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com