From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2058 invoked from network); 27 Aug 1998 07:07:52 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 27 Aug 1998 07:07:52 -0000 Received: (from list@localhost) by math.gatech.edu (8.9.1/8.9.1) id DAA29029; Thu, 27 Aug 1998 03:01:05 -0400 (EDT) Resent-Date: Thu, 27 Aug 1998 03:01:05 -0400 (EDT) Date: Thu, 27 Aug 1998 09:03:37 +0200 (MET DST) Message-Id: <199808270703.JAA02495@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@math.gatech.edu In-reply-to: "Bart Schaefer"'s message of Wed, 26 Aug 1998 10:27:31 -0700 Subject: Re: EZ-compctl (was Re: ideas: free-search-complete, noexpand) Resent-Message-ID: <"zCn4y3.0.W57.nGGvr"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/4365 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu Bart Schaefer wrote: > ... > > } What we currently know as key functions that do completion would be > } implemented as widgets. The completion functions we have now are > } builtin widgets but others can be defined by the user. > > Sort of, but not widgets in the sense of existing zle widgets (that is, > I don't want to have to choose just one of them to bind to the TAB key). > When you say: > What I meant was: all the mechanisms needed to reimplement each of the currently existing completion key functions would be available to the user, for compatibility we would preserve them as builtin key functions. Of course, since everything need to rimplement them should be broken in several parts, users would be able to define completion functions with behaviors different from all currently known completion functions. > } Such a widget for completion would select a shell function that > } produces the matches. I.e., no more compctls but shell functions that > } use the builtin to produce matches and that use `if...then' and other > } things for things we now do with `-x' (which will become obsolete). > > I wasn't thinking of quite so much differentiation between the "widget > for completion" and the "function that produces the matches"; that is, > there's no reason the widget couldn't produce the matches directly, > and no reason the function that produces the matches couldn't also e.g. > set the autoremovable suffix or specify that menu completion be used. > Of course. The shell functions called to produce the matches would just be shell functions in the same special `calling environment' as the widget. So this widget itself would be able to produce matches and the functions called would be able to say something about how matches should be inserted, presented to the user, or whatever. If we use something like `completion contexts', these could be modified even outside any of these functions. (There would be a bit of a problem with the allocation behavior of the completion code, since we would need these context and the matches in them be allocated in real memory where the completion code now uses heap memory.) > (It'd also be great if every match in the list could have some of its > own attributes, e.g. prefix and suffix strings, -U-ness, etc. But I > think that can wait for the next overhaul.) > My patch for inclusive-ors already does this for many of the different things for which it would be useful (-P, -S, -U, and for -Q it was always done). > > } After all selected completion-producing shell functions have been > } executed, the widget uses the builtin to say what should be presented > } to the user (e.g. show a list of matches, change the command line, or > } both, or...). > > Possibly. I was hoping all that could be set up in advance, i.e. during > generation of the matches, and then applied when the entire match list > was finally available. (Maybe that would require per-match attributes, > which I just wrote off for now. Hm.) > As I wrote, here I was thinking only about things like `should we show a list?', not about things like `how should this match be inserted?', that can (and should) be defined when the matches are generated. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de