From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9122 invoked from network); 6 Sep 2000 07:00:56 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 6 Sep 2000 07:00:56 -0000 Received: (qmail 3981 invoked by alias); 6 Sep 2000 07:00:52 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12746 Received: (qmail 3974 invoked from network); 6 Sep 2000 07:00:51 -0000 Message-ID: <20000906070048.11008.qmail@web1103.mail.yahoo.com> Date: Wed, 6 Sep 2000 00:00:48 -0700 (PDT) From: Felix Rosencrantz Subject: Re: Completing parameter names that have yet to be set. To: zsh-workers MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Way back in August in workers/12608, Sven Wischnowsky wrote: >> ... >> >> It seems that the ability to configure styles based on additional >> information not found in the context requires the ability to treat a >> group of styles as a single whole, and quickly set/unset a group of >> styles. I vaguely remember something like this was talked about, but >> don't remember what was decided. > >I only said several times that I would wish I had an idea how to do >that ;-) > >This kind of feeling comes from the times when I wished we had easy >ways to support multiple sets of , >e.g. histories, key bindings, etc. So I took a quick look at Src/Modules/zutil.c which implements zstyle. It looks like all the styles are held in a list pointed to by the static global "zstyles". It seems like it wouldn't be too hard to be able to maintain multiple lists that the value of zstyles could then be pointed to. The multiple lists could be stored as the values in a hash table, the keys would be the names of these lists. There would need to be user command(s) to set the name of the current list, get the names of the lists, set the name of the current list. To edit a zstyle list, you need to make that the current list pointed to by zstyles. Seems like something like that would allow having multiple configuration sets, and being able to quickly change them. And wouldn't require too many changes to the existing source code. How does that seem? Useful? Easy to implement or are there a lot of issues I missed? Also, I while looking at zutil.c, I noticed that the function evalstyle() only modifies the existence of the parameter reply. Would it be useful to provide a parameter that said what the current context is? It seems it might make it possible to write some generic functions that could be given to a "zstyle -e" and make some decisions based on the context. The current context can be different from the context supplied to the zstyle command. The context provided to the zstyle command could be a pattern. Maybe I need to get some rest... :) -FR __________________________________________________ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/