From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17446 invoked from network); 5 Nov 1999 07:20:57 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 5 Nov 1999 07:20:57 -0000 Received: (qmail 20770 invoked by alias); 5 Nov 1999 07:20:48 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8557 Received: (qmail 20763 invoked from network); 5 Nov 1999 07:20:46 -0000 From: "Bart Schaefer" Message-Id: <991105072029.ZM29130@candle.brasslantern.com> Date: Fri, 5 Nov 1999 07:20:29 +0000 In-Reply-To: <199911040932.KAA11903@beta.informatik.hu-berlin.de> Comments: In reply to Sven Wischnowsky "Re: completion grouping" (Nov 4, 10:32am) References: <199911040932.KAA11903@beta.informatik.hu-berlin.de> X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-workers@sunsite.auc.dk Subject: Re: completion grouping MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Nov 4, 10:32am, Sven Wischnowsky wrote: } Subject: Re: completion grouping } } Bart Schaefer wrote: } } > I'm also never sure what to expect from "sorted by priority." In this } > case a smaller number is a higher priority, right? But a negative } > number is treated as bigger than any positive one? That's a bit weird. } > Or am I misunderstanding? } } No. Only tags with a positive (or zero) priority are used and then } smaller numbers mean higher priorities (hm, maybe we should change } that if people think that that would feel more natural). Not necessarily "more natural." } > } comptag option+='*dvi*=1' } > } } > } the `+=' means that the definition is prepended to the already } > } existing definition } > } > Hrm. I would have expected += to *append* rather than *prepend* (my } > C++ is showing). } } Looking at my mail again I noticed that I forgot to mention that `+=' } prepends and `=+' appends. With that said this hopefully looks more } sensible ;-) Hmm. } But I'd like think about changing this function anyway. I.e. I hope to } find a somewhat easier interface. Currently this is still too near to } the way things are stored in `$comptags' and I think the user shouldn't } have to worry/know about the internal representation. I don't see how you can avoid having the user know *something* about at least the ordering of the alternatives for a given tag, so although I'm not entirely happy with the syntax I don't mind the semantics. } we probably should think about some standard structure for defining } styles. Things like multiple styles (separated by commas?), styles } with values (`[style_a=foo,style_b=bar]' or something like that). If } this turns out to be useful, I would like change `_tags' to report } styles in a format that is easier to parse in the calling functions. I repeat my suggestion that this be enveloped in a mini-language, as with the _arg_compile function. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com