From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23840 invoked from network); 2 Nov 1998 11:37:20 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 2 Nov 1998 11:37:20 -0000 Received: (from list@localhost) by math.gatech.edu (8.9.1/8.9.1) id GAA13102; Mon, 2 Nov 1998 06:30:47 -0500 (EST) Resent-Date: Mon, 2 Nov 1998 06:30:47 -0500 (EST) Message-Id: <199811021129.LAA11861@diamond.tao.co.uk> Subject: Re: completion behaviour (was: zsh-workers: zsh-3.1.5 released) To: wischnow@informatik.hu-berlin.de (Sven Wischnowsky) Date: Mon, 2 Nov 1998 11:29:15 +0000 (GMT) From: "Zefram" Cc: zsh-workers@math.gatech.edu In-Reply-To: <199811021036.LAA22116@beta.informatik.hu-berlin.de> from "Sven Wischnowsky" at Nov 2, 98 11:36:33 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"dXqL83.0.fC3.dVPFs"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/4497 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu Sven Wischnowsky wrote: >We had some discusssion about a new way to define completion behaviour >which (seemingly) settled on: let's use shell functions and offer a >few new builtins. So, if I implement this, do we really want the >changes to compctl (note: I mean compctl, most of the changes in the >completion code itself would be used anyway) or should we leave >compctl alone and offer the new possibilities through the new way to >define completion behaviour, thereby giving some incentive to switch >to the new way? I wondered about this myself, but came to the conclusion that new completion features should be made available via compctl until the new interface has been implemented. After the new interface is in place we can freeze compctl. >We use zle widgets, probably a new kind of widgets that uses some more >special variables, like: We can have a single widget that acts as the main interface to completion, creating these variables and calling user-defined widgets to do the real work. >To make the definition and calling of completion functions for certain >commands easier there could be a new builtin, say `compfunc': I'm not convinced by this. I'd rather get associative arrays working, and use a non-special array to store this information. I'd like the user to be able to totally redefine the way that completions are associated with command names. >For producing the actual matches there is another builtin, say >`compadd'. For simplicity we could make it use the same flags >`compctl' uses now, but without `-x', `+', and the like, i.e. only the >simple match-producing flags. This would allow us to re-use most of >the code for compctl and since only the simple flags would be >supported, the irritating part of compctl would not be inherited. Yes, this is good. I was wondering how to make the match structures user accessible. Using the compctl-style interface to build up a specially-handled list of matches solves this, and gives the user access to the full power of the completion system. OTOH, I think this perhaps should be split into two builtins. One to add sets of matches in a manner based on the compctl syntax (this could even be part of the compctl module, and use the compctl code to handle *all* the compctl options). Another, more basic builtin would merely provide an interface for adding a single match (or a set of matches), with options to separately control each part of the match structure. >is a problem with this: with compctl the `-x' - tests not only test >for a certain condition, but also report some information back, >namely: the length of an prefix that should be ignored in the >completion string This should be part of the match structure, and the user should be able to control it explicitly. -zefram