From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29181 invoked from network); 3 Nov 1998 16:10:00 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 3 Nov 1998 16:10:00 -0000 Received: (from list@localhost) by math.gatech.edu (8.9.1/8.9.1) id LAA20683; Tue, 3 Nov 1998 11:00:56 -0500 (EST) Resent-Date: Tue, 3 Nov 1998 11:00:56 -0500 (EST) Date: Tue, 3 Nov 1998 16:58:54 +0100 (MET) Message-Id: <199811031558.QAA28492@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@math.gatech.edu Subject: new completion behaviour version 2 Resent-Message-ID: <"rWhfh2.0.635.uYoFs"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/4516 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu Ok, here is the update I promised... We need some kind of C-wrapper function around the completion code, so we either have one new builtin widget that calls a shell function to do the real work or we have a new type of user-defined-widgets which do the work, probably calling other shell functions to produce the matches. Information about the context for producing the matches is normally obtained in the top level shell function (or the new-type widget), stored in local variables and thereby made accessible in called functions, but of course users can implement this differently. Of the information that is important to have the command words and the index into this array are already available via `read'. The prefix and suffix can be made accessible via `read', too, or as arguments when calling the top level function (as with compctl-K-functions). Another interesting information is the environment, i.e. `condition', `redirection', and the like, which could be made accessible like the prefix/suffix. To be able to implement things like xor'ed completion in a shell function we need a way to access the number of matches produced so far. This information differs from the other ones because it changes whenever matches are added (of course). If we avoid special variables for all the other things we shouldn't add one for this, so the users will have to call `read' repeatedly to get the current number of matches. Since most people will put their completion definitions in shell functions, we need a way to at least map strings (command names) to other strings (function names). This will be done either with associative arrays or with the `$funcs[$cmds[(i)$CMDNAME]]'-trick. For command name patterns we can start using a simple array until we find something more clever. For producing matches we have a new builtin that uses the compctl-flags (and part of it's code) to specify which matches should be generated. Either this builtin or another new builtin will support a way to directly set all the different things that are stored together with the matches. The coding scheme for xor'ed completion is trivial. The code for `-x' stuff will be done using `if'-tests with the information stored in local variables. We then need a way to notify the completion code about two things it will have to use (to be able to do the same things `-x' can): the length of an ignored prefix of the current word and (for `-L') which part of the words-array should be taken as command words. Of course we should do this in a very general manner, giving users the possibility to report restrictions `-x' doesn't use. To be able to correctly save/restore this type of information we will need a way to get the current state in a way that can be used to restore it later (so that independently developed completion functions can restore the restrictions to the state they were in when the function was called). All this could be done with the builtin that produces the matches (or the one that gives full control over the match structure if we put this into a separate builtin). Finally we need a way to put a match in the command line and to list matches. Listing is simple (one way or the other). More interesting is putting matches on the line. I still find it tempting to think about ways to use the special variables [LR]BUFFER for this. The only problem with this are automagically removed suffixes (getting the prefix/suffix from the completion code is simple nowadays). So if we add a way to make removable suffixes completely user-controllable this may be the best solution (and giving the user full control over this is interesting in itself, just think about the `compctl ... -S/ -q' example from Bart). So we would end up with a builtin that allows one to retrieve information about the matches (the prefix/suffix to insert, and probably all the other things stored with the matches), starting a new set of matches, listing them, and so on. With this builtin we could also let users remove specific matches, change them, etc. All this could later be added if we find uses that make them desirable. So, I hope this approach is simple enough. Comments? Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de