From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24238 invoked from network); 16 Nov 1998 10:06:27 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 16 Nov 1998 10:06:27 -0000 Received: (from list@localhost) by math.gatech.edu (8.9.1/8.9.1) id EAA11909; Mon, 16 Nov 1998 04:55:59 -0500 (EST) Resent-Date: Mon, 16 Nov 1998 04:55:59 -0500 (EST) Date: Mon, 16 Nov 1998 10:54:03 +0100 (MET) Message-Id: <199811160954.KAA10377@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@math.gatech.edu In-reply-to: Peter Stephenson's message of Sat, 14 Nov 1998 16:26:40 +0100 Subject: Re: Associative arrays and memory Resent-Message-ID: <"n5MFV1.0.zv2.kQ_Js"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/4648 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu Peter Stephenson wrote: > ... > > So, the question is are there any uses for special hashes which would > require tying them directly to an internal variable or function, or > can they always be accessed by the standard parameter functions? I > would think the whole point of using assoc arrays is to avoid any > unpleasantness of the former kind. Probably Sven can answer that > better than anyone. When thinking about using assoc. arrays for completion (and zle widgets) I think of two uses: the one Bart mentioned in his reply (`zle[...]') for access to various zle internals and one for the mapping of command strings or environments to function( name)s which produce the matches. The second one would be fully user-controlled (in the sense that the user might use it if (s)he wishes but the completion code wouldn't enforce it). Hence this one would make no trouble. The first use might cause some trouble, you already described the current use of LBUFFER and so on. For the completion stuff I'm not yet sure if we really need/should have settable parameters. If they are settable it shouldn't be too hard to access their values via the normal parameter interface (although making them special would probably make things cleaner and easier to add the new things we may one day find interesting). So, I would like to reduce it to the question if we should use an assoc array for the zle information or not. Using an assoc array only for this may look a bit queer unless we use them in other places, too. (Every time I think about this I can't help remembering the discussion about a new option system, am I the only one?) Two more things about assoc arrays: typeset -A foo foo[hello]=world echo $foo[(i)w*] gives `1', this should be `hello'. And if we use an assoc array for completion command name patterns we would need pattern matching the other way round: the keys are taken as patterns and `$funcs[(x)$cmdstr]' (for some value of `x') should give the values of all entries whose key (taken as a pattern) match the value of $cmdstr. But of course we could use a simple array for the patterns and loop through it (the question is: are there other uses where such a feature might be interesting to have, and: if we have a way to get a list of matching entries, should we make this with a new modifier flag that can be combined with `i', `I', `r', and `R' so that all of them give a list, not only the first matching one?). Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de