From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7111 invoked from network); 1 Apr 1999 07:20:40 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 1 Apr 1999 07:20:40 -0000 Received: (qmail 13211 invoked by alias); 1 Apr 1999 07:19:54 -0000 Mailing-List: contact zsh-users-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 2274 Received: (qmail 13204 invoked from network); 1 Apr 1999 07:19:53 -0000 Date: Thu, 1 Apr 1999 09:19:51 +0200 (MET DST) Message-Id: <199904010719.JAA09326@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-users@sunsite.auc.dk In-reply-to: Greg Badros's message of 31 Mar 1999 15:12:48 -0800 Subject: Re: Updating the Xterm title with every execution? Greg Badros wrote: > 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.). Obviously I wasn't clear enough... I have no objections to put that into 3.0.6. But I wouldn't like to see an option to be used for it because people would then expect this option to be in 3.1x, too. And since I wouldn't like to see a feature as specific as this to be in the standard completion module and because modules currently can't define their own options, we would have to put it into the core. With the modules in 3.1. it would be easy to put enhancements like this one into separate modules, which, as I hope you agree, is much cleaner. As for the different implementation: I didn't suggest *replacing* your stuff with something different. At least I *wanted* to suggest that by moving it into a separate module in 3.1. we could give the user a way to decide if he wants to use your implementation (which would be one module), or another implementation (which would give a bit more control to colourise non-filenames and more and would be in another separate module). The user would chose what he wants just by including one (or none at all) of these modules. > > 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? I hope this is clear now -- backward-compatibility. And you don't need the option if you make your patch alwasy use the parameter `ZLS_COLOUR' (or whatever) and turn on colours only if that parameter is set. The name should be seldom enough to not interfere with any existing parameter name. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de