From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1200 invoked from network); 9 Nov 1998 23:14:32 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 9 Nov 1998 23:14:32 -0000 Received: (from list@localhost) by math.gatech.edu (8.9.1/8.9.1) id SAA11369; Mon, 9 Nov 1998 18:11:11 -0500 (EST) Resent-Date: Mon, 9 Nov 1998 18:11:11 -0500 (EST) From: "Bart Schaefer" Message-Id: <981109150938.ZM19408@candle.brasslantern.com> Date: Mon, 9 Nov 1998 15:09:37 -0800 In-Reply-To: <199811090904.KAA07856@beta.informatik.hu-berlin.de> Comments: In reply to Sven Wischnowsky "Re: new completion behaviour version 2" (Nov 9, 10:04am) References: <199811090904.KAA07856@beta.informatik.hu-berlin.de> X-Mailer: Z-Mail (4.0b.820 20aug96) To: zsh-workers@math.gatech.edu Subject: Re: new completion behaviour version 2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"_-7BK2.0.an2.FQtHs"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/4593 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu On Nov 9, 10:04am, Sven Wischnowsky wrote: } Subject: Re: new completion behaviour version 2 } } Bart Schaefer wrote: } > } > That is, the widget can say "here are the completions, and here is where } > you insert them" but then let hardwired code take over cycling through } > the menu if there are multiple matches. } } Interesting point of view. I thought we wanted to give the user the } possibility to build widgets that have full control Well, yes, that's why I said I could easily be convinced otherwise; but: } > Listambiguous can be a flag attached to the generated } > list of matches, can it not? } } Yes. The question is: should the completion code do this automatically } or should the user request it explicitly. It's quite a burden on the widget writer to check for LISTAMBIGUOUS and spit out the listing if so. On the other hand, the widget ought to be able to emit a listing (and have zle deal with it properly) even when the LISTAMBIGUOUS is not set. It seems to me there are three ways to deal with this: 1. The widget function always produces the entire list of matches, with an annotation for how and where to insert them. + Returning a single value forces recexact. + The function always executes in the same way and always returns the same values, so its easier to write. + Efficient, compiled builtin code handles menus and listings, and tests for menucomplete, automenu, autolist, and listambiguous. + There's only one call to interpreted user code per set of results. - The annotations have to describe prefix/suffix removal, replacement, or addition for correct insertion on the command line. - It may be unclear exactly what to display in a listing, i.e., what if any prefix/suffix changes to perform on the returned strings. 2. The widget function always produces one match at a time, with an annotation for how and where to insert it. + Builtin code still tests for menucomplete, automenu, autolist, and listambiguous. + The function can change the insertion annotations on every match. - The function has to be told which match to produce; it's harder to write efficient functions because it's necessary e.g. to branch on whether the full list has previously been generated and on whether the prefix has changed. - Lots of calls to interpreted code when generating listings and when cycling through menus. - It requires either an annotation or two calls to the function to force recexact. - It still may be difficult to determine what to display for a listing. 3. The widget function not only produces the matches, but also either inserts them or produces a listing as appropriate. + The function can drive zle directly (e.g., through $BUFFER) to do complex insertions/changes. + No annotations are needed. + The function can produce exactly what should appear in the listing. - The function has to be told what match to produce or to produce a complete list of possible matches; it's even harder to write simple efficient functions. - Lots of calls to interpreted code when generating menus. - The widget writer has to figure out all the prefix/suffix changes to perform on every insertion, including dealing with menus (but an implicit "undo" of the last insertion before calling the function for the next item could make that easier). - The widget itself has to test automenu, autolist, and listambiguous. There are of course points somewhere in between each of these choices, but they all have something of those flavors. I think the choice of which to provide depends on what we can come up with in terms of the annotations needed by the first two. } > compadd $disabled } > instead of } > compadd -dFB } } I like this. But I wouldn't like to have to do } } compadd $(compinfo -disabled) I agree; if the choice is between that and something like compadd disabled then I'd take the latter. } > [[ ]] to mean "test completions", e.g., [[ -C index -1 / ]] for the } > above.) } } I didn't think about changing [[...]], interesting. (Although that } would require changes in completely differnt parts of the code, of } course.) Yes, but I've been thinking that perhaps the tests supported by [[ ]] should be extensible through the modules mechanism anyway. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com