From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20895 invoked from network); 1 Mar 1999 12:33:12 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 1 Mar 1999 12:33:12 -0000 Received: (qmail 21679 invoked by alias); 1 Mar 1999 12:32:29 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 5567 Received: (qmail 21671 invoked from network); 1 Mar 1999 12:32:27 -0000 From: "Andrej Borsenkow" To: "Sven Wischnowsky" , Subject: RE: PATCH: completion parameters etc. Date: Mon, 1 Mar 1999 15:31:31 +0300 Message-ID: <003601be63df$6fddb450$21c9ca95@mowp.siemens.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2013.2901 In-Reply-To: <199903011210.NAA14601@beta.informatik.hu-berlin.de> > -----Original Message----- > From: Sven Wischnowsky [mailto:wischnow@informatik.hu-berlin.de] > Sent: Monday, March 01, 1999 3:10 PM > To: zsh-workers@sunsite.auc.dk > Subject: PATCH: completion parameters etc. > > - `list': May be `list', `autolist', `ambiguous' or unset. Can be > used to control the completion listing behavior by setting it to > one of these values. > - `insert': May be `unambiguous' (for non-menucompletion), `menu', > `automenu' or unset (for listing-only). May be set to control if > and how the command line should be changed. > - `exact': Set to `accept' or unset by the completion code. May > also be set to `accept' or unset. This controls if `REC_EXACT' > should be used. Only too late I thought about adding a key > `exact_string' that can contain the string itself. I may produce > a patch for this later. 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? regards /andrej