From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2443 invoked from network); 31 Mar 1999 23:14:05 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 31 Mar 1999 23:14:05 -0000 Received: (qmail 21664 invoked by alias); 31 Mar 1999 23:13:04 -0000 Mailing-List: contact zsh-users-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 2272 Received: (qmail 21617 invoked from network); 31 Mar 1999 23:13:00 -0000 Sender: gjb@cs.washington.edu To: Sven Wischnowsky Cc: zsh-users@sunsite.auc.dk Subject: Re: Updating the Xterm title with every execution? References: <199903311135.NAA08267@beta.informatik.hu-berlin.de> From: Greg Badros Date: 31 Mar 1999 15:12:48 -0800 In-Reply-To: Sven Wischnowsky's message of "Wed, 31 Mar 1999 13:35:50 +0200 (MET DST)" Message-ID: X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sven Wischnowsky writes: > > > > 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 Why is an option a problem? It's cleaner to use an option then to have it be only a compile-time flag. There are plenty of other options affecting completion (listambiguous, listtypes, menucomplete, etc.). > 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?). Making it more zsh-ish defeats one of the goals which is transparent interoperability with colorized GNU ls output-- my Zsh patch uses the same configuration mechanism as that (and the same code, largely). > 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 Sure, but that's for 3.1, not 3.0.6. > 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). I do not know what you mean use only "ZLS_COLOR". Why is that better than setopt listcolors? > 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... Sure, and it'd be great if 3.0.x had dynamic module support so everyone could be happy, but for very little space, you get a feature that is pretty darn useful, and helps zsh interroperate better with one of the most used commands (ls). Greg P.S., here's the size difference on an x86 compiled with egcs-1.1.x. 397 -rwxrwxr-x 1 gjb contrib 402882 Feb 9 16:46 zsh-3.0.5* 402 -rwxr-xr-x 2 gjb visitors 407740 Mar 19 18:18 zsh-gjb* (zsh-gjb includes my patch for both post-prompts and colorized-completion)