From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24691 invoked from network); 31 Mar 1999 11:40:22 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 31 Mar 1999 11:40:22 -0000 Received: (qmail 6709 invoked by alias); 31 Mar 1999 11:36:02 -0000 Mailing-List: contact zsh-users-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 2267 Received: (qmail 6702 invoked from network); 31 Mar 1999 11:36:01 -0000 Date: Wed, 31 Mar 1999 13:35:50 +0200 (MET DST) Message-Id: <199903311135.NAA08267@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-users@sunsite.auc.dk In-reply-to: Greg Badros's message of 30 Mar 1999 02:27:53 -0800 Subject: Re: Updating the Xterm title with every execution? Greg Badros wrote: > "Bart Schaefer" writes: > > > } Please correct me if I'm wrong, but I don't think 'preexec' exists in > > } Zsh 3.0.5 > > > > It's in 3.0.5-ext-2, available from ftp.brasslantern.com:/pub/zsh/, which > > will be the basis of 3.0.6 appearing (I hope, if I get the archive scripts > > learned soon) sometime this month. > > That's great-- any chance of getting my colorized completion patch in > there? It's plenty clean, has it's own option, and is pretty small -- > it could be a compile-time switch if you're *really* concerned about > memory footprint (zsh 3.0.x still does not have any dynamic loading > capabilities, does it?). Since 3.0.6 is the end of the road for 3.0, > the maintenance headache of another compile-time flag is not an issue. The problem I have with this is that it uses an option. In 3.1. I would like to make the code in `zle_tricky.c' use a pointer variable to call `listmatches()' to allow stuff like this to be put in a different module that may be loaded on top of `compctl'. We can then also add a different colourisation module which is a bit more zsh-ish. Probably using a assoc array to map patterns/descriptions to strings like `%B%n%b' where the `%n' gets replaced by the string (of course, the best way would be to allow different maps for different completions, but we could already use group names for that). Or something like that. This should be easy to use because I think that sometime we will be able to make modules autoloaded on parameter names (haven't really looked for that in the code yet, but every parameter name lookup goes through the paramtab-hashtable functions, right?). Of course, if we add a way to allow modules to define options and make modules autoloaded on them, nothing could be said against using a option for it (well, something could be said against it: it's superfluous -- even in your patch making it use only `ZLS_COLOR' (or turning it into an array and giving it a better name) and testing if that is set would be enough). Anyway, I don't think that I'll ever use a feature like this and so would be against putting it into the zsh core itself. But it's not my duty to decide this... Bye Sven P.S.: Module-defined options may also be an argument for moving to a assoc array based option system. -- Sven Wischnowsky wischnow@informatik.hu-berlin.de