From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11127 invoked from network); 11 Feb 1999 07:51:31 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 11 Feb 1999 07:51:31 -0000 Received: (qmail 714 invoked by alias); 11 Feb 1999 07:51:07 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 5336 Received: (qmail 705 invoked from network); 11 Feb 1999 07:51:02 -0000 From: "Bart Schaefer" Message-Id: <990210235049.ZM1108@candle.brasslantern.com> Date: Wed, 10 Feb 1999 23:50:49 -0800 In-Reply-To: <9902101626.AA46190@ibmth.df.unipi.it> Comments: In reply to Peter Stephenson "Re: PATCH: compadd (+ questions)" (Feb 10, 5:26pm) References: <9902101626.AA46190@ibmth.df.unipi.it> 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 10, 5:26pm, Peter Stephenson wrote: } Subject: Re: PATCH: compadd (+ questions) } } 1) I suspect most people are going to use much of it as it stands, and } just alter what they want. (Who the *other* people might be, I cannot } imagine.) So might it be an idea to find a more general name than } my-comp, and also to define widgets using main-complete for all the } standard completion functions, not just expand-or-complete? And } perhaps do some trickery with bindkey output to rebind any keys using } the old ones to the new ones? Some way of supplying options to } new-completion-examples would be good. } } 2) Currently, existing compctl's take precedence over any of the new } style functions for given commands. That's sort of reasonable at the } moment, since many of the new-style functions are examples rather than } complete systems. I wonder if there's a better way of deciding this. } If we implement something like 3), it might be better for the } new-style ones to take precedence. Addressing both of these questions together: I do think it's a good idea to make the examples as directly usable as possible, and therefore to carefully choose descriptive names for the various functions (nothing so uninformative as "my-comp" nor as generic as "files"). It's probably also a good idea to have separate examples emulating as many of the old built-in completions as possible, so that people have "building blocks" from which to construct completions that have effects similar to the built-in set or combinations thereof. That'll also provide a good set of test cases to see whether we've (a) achieved the goal of writing something more understandable than compctl, and (b) made all the necessary bits of the functionality available to the shell script programmer. However, for the simple cases I'm concerned that calling interpreted shell functions will be "too slow" and we shouldn't encourage people to simply load up the examples en masse. Has anybody done any speed comparisons on having zsh call the old-style compctls directly, vs. the new-style stuff firing `compcall`, vs. doing the entire thing with the new stuff? I confess I haven't had much chance to play with this. } 3) As far as the example functions are concerned, it might be an idea } to separate them out into their own directory so they can be } autoloaded or copied for autoloading. How about this: they get } separated into a directory, and then some code in the main file scans } that directory and decides file by file how to call defcomp. This sounds like a good idea. BTW, defcomp and friends could use some more commenting up front. The meaning of, say, "--default--" as the second parameter to defcomp should be explained near the definition of defcomp, either instead of or as well as down in main-complete when the associative array is finally referenced. ---------- As to goal (a) above: This is the first time I've really taken the time to read through the new-completion-examples file, and I find myself disappointed by a couple of things that sounded good in theory. Part of it may just be Sven's coding style; can we use better variable names than "a", "b", c", "opa", "epre", and "ppres", please? It's bad enough having that in the C code, without exposing mere mortals to it. I think the worst are the new switches for the conditional expressions, particularly the ones that take two following strings; it looks wrong. I just spent several minutes pondering whether [[ -word CURRENT-1 -ef ]] would look better to me than [[ -current -1 -ef ]], and decided it's only marginally better. It using -current or -word a lot faster than using [[ $@[CURRENT-1] == '-ef' ]]? Are they doing some other magic? For the conditionals that don't use two strings, I think some of the keywords could be better, but I don't yet have a list of suggestions. Maybe it's just the 'm' prefix on the ones that take a pattern that bothers me, and which also makes me wonder for a moment whether there's supposed to be a -matches is when I see that there's a -nmatches. Also, and I apologize for not responding more immediately to Sven from zsh-workers/5083, I must say that the way that -iprefix, -position and -string have parameter-modifying side-effects makes me cringe. It'd be fine in another new builtin, but a [[ ]] with side-effects?!? Yipes! Don't go changing anything yet just on the basis of my opinion, though; I'm only trying to hear some discussion about this stuff. I realize that the side-effects are merely mirroring the state of the completion internals, I just question letting this happen from [[ ]], and maybe whether there should be a builtin equivalent of compsave/compreset. I should close by saying that I *am* impressed, overall, with the new completion scheme and the possibilities it presents. I'm particularly glad of way it and PWS's completion widgets were able to collapse into one system. I think the progress is good, and that we should keep on speeding towards something even more marvelous. (BTW, the contract I was supposed to be starting was postponed until this coming Monday. Once it starts, my contributions will be rather limited for several weeks.) -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com