From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22370 invoked from network); 1 Mar 1999 12:43:26 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 1 Mar 1999 12:43:26 -0000 Received: (qmail 22942 invoked by alias); 1 Mar 1999 12:42:16 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 5570 Received: (qmail 22922 invoked from network); 1 Mar 1999 12:42:11 -0000 Date: Mon, 1 Mar 1999 13:41:28 +0100 (MET) Message-Id: <199903011241.NAA14660@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Andrej Borsenkow"'s message of Mon, 1 Mar 1999 15:31:31 +0300 Subject: RE: PATCH: completion parameters etc. Andrej Borsenkow wrote: > Aha! I had slightly different idea, but yourth is probably more general > anyway ... But for the record ... > > Currently (not as current already :-) we have several ad hoc builtin > completion widgets and use them to describe behaviour of user-defined ones. > My suggestion was actually to define a set of per-widget parameters that > describe how completion behaves and use zle command to set them. > > I call them parameters and not flags because I expect some of them to take > arguments. The problem is to find out the proper set of orthogonal features. > At least list, menu, expand, complete seem to be quite independent. In this > way one could define a widget, that would e.g. list possible expansion (yep, > we already have such a beast). And with menu parameter we could say, at > which attempt should menu start. Zero (disable), one (zsh traditional), two > (bash). > > But here the question: how do your state parameters interact with global > options? Such as automenu etc? With the new compstate-keys we could almost avoid having to give the name of a builtin completion widget to `zle -C' (since users can re-implement anything). But I'd be against this, because (and this is the answer to your question) I think it is very convenient to have a simple way to set the initial values for the keys in a way that make things behave like the widgets one is used to (if they are left untouched by the widget). I.e. currently the `emulated' builtin widget and the option settings are used to set the values when the completion widget is called. After the widget exits, the code uses the current values, so if the widget changed them, the behavior will differ. Of course, options will not be altered by the code. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de