From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22941 invoked from network); 13 Feb 1999 19:20:18 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 13 Feb 1999 19:20:18 -0000 Received: (qmail 16188 invoked by alias); 13 Feb 1999 19:19:56 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 5368 Received: (qmail 16180 invoked from network); 13 Feb 1999 19:19:48 -0000 From: "Bart Schaefer" Message-Id: <990213111937.ZM23172@candle.brasslantern.com> Date: Sat, 13 Feb 1999 11:19:37 -0800 In-Reply-To: <199902120842.JAA08278@beta.informatik.hu-berlin.de> Comments: In reply to Sven Wischnowsky "Re: PATCH: compadd (+ questions)" (Feb 12, 9:42am) References: <199902120842.JAA08278@beta.informatik.hu-berlin.de> X-Mailer: Z-Mail (4.0b.820 20aug96) To: zsh-workers@sunsite.auc.dk Subject: Re: PATCH: compadd (+ questions) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Feb 12, 9:42am, Sven Wischnowsky wrote: } Subject: Re: PATCH: compadd (+ questions) } } > The point being that, although being able to add conditions in modules is } > a cool thing, perhaps we should drop the ones that are easily replicated } > using simple tests on the variables, and then look again at the rest to } > see if there's a better way to express them. } } Agreed, although I'm not sure if I'll produce a patch for this any } time soon. If you're about to do new doc, though, you shouldn't spend time documenting something that's going to go away ... } > tryprefix () { } > complocal # Equivalent of "local CURRENT NMATCHES ...", } > # if "local" worked on special parameters } > comptest ignored-prefix $1 && { shift ; "$@" } } > } } > tryprefix - complist -k "($signals[1,-3])" } } Ah, now I finally understand why you wanting restting in function } scopes. One problem I have with this is that we can come up with a few } functions for the tests, but the things to do if the test succeeds can } often not easily be put in a command line. That's just a matter of more shell functions: listsignals() { complist -k "($signals[1,-3])" } tryprefix - listsignals but you're right that a real syntactic construct would be much cleaner. Maybe we can figure out a way to make "local" work inside { ... } ? I've seen some postings on zsh-users that lead me to believe some people think it does already. } Also we often need combinations of tests, for and'ed tests this would } lead to things like `tryrange -exec \; tryprefix - ...', but for or'ed } tests. You wouldn't do it that way. You'd write a special function for each particular combination of tests you wanted, and then just call them in the appropriate spots. Yes, this is crude, but it's easy to explain and use, in terms of existing zsh scripting concepts. } Also, will the non-parameter-modifying tests have equivalent } functions or will this lead to combinations of such function calls and } `[[...]]' conditions? This can get very hard to read, I think. My thought was that only the tests with side-effects get a builtin. I don't think the mixture will occur often enough to get that confusing. If you don't need to "local"-ize the side-effects, which in at least some cases you won't, you can just write stuff like if test $NMATCHES -eq 0; then ... elif comptest ignored-prefix - ; then ... elif ... ... fi I.e., use "test" if it's really important to avoid mixing [[ ... ]] with plain ol' command syntax. } About using argv for the stuff from the command line. I'm not too } happy with this anyway. If the new style completion is slower than the } old one, this may partly be caused by several calls to sub-functions where } we have to use "$@" to propagate the positional parameters. So don't propagate it via positional parameters after the first level. Having them in the positionals is a convenience for when the top-level completion function doesn't need to be as complex as __main_complete, e.g., when writing special key completions. For Functions/Completion/*, something like this: alias compsub 'words=( "$@" ) __normal || return 1' or just have __main_complete assign to a local $words and then use it in place of $argv in all of the sub-functions. } > So why don't we actually DO that? That is, make a "recursive" call to } > the whole completion system? Add -iprefix, -position, -string, -class } > options to "compcall" (or some similar new command) and have THAT adjust } > the variables, re-invoke the appropriate main completion function, and } > then restore everything } } Only seldom do we want to do normal completion after adjusting the } word/words to use. In most cases we want to do some very specialised } calls to complist/compadd or whatever and we want only those } matches. OK, then, give compcall another parameter that's the name of a different top-level completion function to use. That'd also solve the positional parameter propagation problem we just talked about. Note that I'm talking here about adding functionality to the compcall builtin, not to some new piece in Functions/Completion/. More later ... -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com