From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19457 invoked from network); 2 Apr 1999 01:58:37 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 2 Apr 1999 01:58:37 -0000 Received: (qmail 3557 invoked by alias); 2 Apr 1999 01:58:04 -0000 Mailing-List: contact zsh-users-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 2280 Received: (qmail 3544 invoked from network); 2 Apr 1999 01:58:04 -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: <199904010719.JAA09326@beta.informatik.hu-berlin.de> From: Greg Badros Date: 01 Apr 1999 17:57:57 -0800 In-Reply-To: Sven Wischnowsky's message of "Thu, 1 Apr 1999 09:19:51 +0200 (MET DST)" Message-ID: X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" Sven Wischnowsky writes: > 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. Ah, yes... now this makes much more sense to me. Though why can't executing a setopt load a module (as invoking a function loads that function)? Similarly, I've wanted this for completion controls, too -- scanning all my completion stuff takes forever at startup-- it'd be nice to have them autoloaded when I first try to complete (ignorance warning: I've not been following the 3.1.x discussion on completion stuff so maybe people are working on this or something similar). > > 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. This seems reasonable, and I'd be glad to make the colorized completion stuff work as you suggest so as to not burden the 3.1 implementation unnecessarily. Thanks for your clarification. Greg