From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17969 invoked from network); 11 Feb 1999 18:26:49 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 11 Feb 1999 18:26:49 -0000 Received: (qmail 13333 invoked by alias); 11 Feb 1999 18:26:19 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 5345 Received: (qmail 13323 invoked from network); 11 Feb 1999 18:26:10 -0000 From: "Bart Schaefer" Message-Id: <990211102553.ZM3491@candle.brasslantern.com> Date: Thu, 11 Feb 1999 10:25:53 -0800 In-Reply-To: <199902110909.KAA05147@beta.informatik.hu-berlin.de> Comments: In reply to Sven Wischnowsky "Re: PATCH: compadd (+ questions)" (Feb 11, 10:09am) References: <199902110909.KAA05147@beta.informatik.hu-berlin.de> <9902110911.AA53573@ibmth.df.unipi.it> <199902110938.KAA05365@beta.informatik.hu-berlin.de> In-Reply-To: <9902110911.AA53573@ibmth.df.unipi.it> Comments: In reply to Peter Stephenson "Re: PATCH: compadd (+ questions)" (Feb 11, 10:11am) In-Reply-To: <199902110938.KAA05365@beta.informatik.hu-berlin.de> Comments: In reply to Sven Wischnowsky "Re: PATCH: compadd (+ questions)" (Feb 11, 10:38am) 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 11, 10:11am, Peter Stephenson wrote: } Subject: Re: PATCH: compadd (+ questions) } } Sven Wischnowsky wrote: } > > Some way of supplying options to } > > new-completion-examples would be good. } > } > I don't understand what kind of options you mean here. } } Sorry, I wasn't clear about that. I meant that if people are going to } be using whatever-it's-going-to-be-called more or less en bloc, it } would be helpful to have ways of telling it whether or not to bind the } widgets it's just defined (and maybe other things like that). } However, since it's almost certainly going to be sourced, it's hard to } supply options in a simple way. Eh? zsh% source =(echo 'echo $0: $*') these are the args /tmp/zsha00834: these are the args } I, too, found the new [[-tests a little confusing at first sight. I'm } inclined to think maybe they should be limited to those that can't be } done so easily in the standard way. For example, I don't see why } people shouldn't use (( NMATCHES )) rather than [[ ! -nmatches 0 ]] . } But I haven't really got a proper grip on using this yet. This is what I'm thinking, too. I may be getting my chronology confused, but wasn't it the case that the new condition codes showed up before all the variables for NMATCHES and CURRENT etc. were available? There's a short list of stuff you can't easily do with the variables: 1. Automatic shifting of bits of PREFIX into IPREFIX, as -iprefix does and as -string and -class do with two args. 2. Adjusting the range of words used, as -position does with two args. 3. Skipping exactly N occurrences of an embedded substring, as -string and -class do with two args. Have I missed any others? Sven didn't answer my question about whether the remaining condition codes are faster or have other side-effects: On Feb 11, 10:38am, Sven Wischnowsky wrote: } Subject: Re: PATCH: compadd (+ questions) } } Bart Schaefer wrote: } } > 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? Sven? 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. Unless there's a reason not to, such as, interpolating the string values of the variables during parsing of the expression is significantly slower than recognizing the new codes themselves (which I don't know whether or not is the case). } For really clean completion functions we would need a new control } structure to be able to put all tests into one function and having } everything reset to the previous state automatically. Doing something } like: } } if comptest iprefix '-'; then } ... } compreset } else } } wouldn't be that easy to glark, too. I still think the right way to do this is with shell-function scoping. tryprefix () { complocal # Equivalent of "local CURRENT NMATCHES ...", # if "local" worked on special parameters comptest ignored-prefix $1 && { shift ; "$@" } } tryprefix - complist -k "($signals[1,-3])" The unfortunate thing about this is that it clashes with $argv holding the command line (but that's true of any function called from within the top-level main-complete function, isn't it?). There should probably be another array that also holds the words, but I guess it isn't that hard to have the main completion function set up a global for it. Looking at the above gives me a nagging idea ... it's half-formed at the moment, but it goes something like this ... The effect of `compsave; [[ -iprefix ... ]] ; compreset` is that we want to try a completion with a particular prefix and if that fails, start over with the original state and try again. Similarly for -position to limit the range of words, etc. 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 if that function returns nonzero. It would then be an advertized side-effect of compcall that, if it returns nonzero, the state of the completion variables has been adjusted -- which makes a lot more sense to me than having a conditional do it. Then most if not all of the completion-related conditionals can go away. However, I don't really understand yet the interaction of (say) adding matches for menucomplete that rely on a prefix in one place, and adding more matches for the same completion in another place that rely on a different prefix, with the state of the completion variables in both places. Maybe the variables should simply ALWAYS be restored when the recursive compcall unwinds; or maybe there's some other interaction that makes this whole idea unworkable. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com