From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9483 invoked from network); 10 Jun 1998 06:30:21 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 10 Jun 1998 06:30:21 -0000 Received: (from list@localhost) by math.gatech.edu (8.8.5/8.8.5) id CAA00732; Wed, 10 Jun 1998 02:26:05 -0400 (EDT) Resent-Date: Wed, 10 Jun 1998 02:26:05 -0400 (EDT) From: "Bart Schaefer" Message-Id: <980609232639.ZM9523@candle.brasslantern.com> Date: Tue, 9 Jun 1998 23:26:39 -0700 In-Reply-To: <199806092002.VAA05396@taos.demon.co.uk> Comments: In reply to Zefram "Re: User-defined zle widgets and built-in widget failure" (Jun 9, 9:02pm) References: <199806092002.VAA05396@taos.demon.co.uk> X-Mailer: Z-Mail (5.0.0 30July97) To: Zefram Subject: Variable namespaces, goals for ZLE, etc. Cc: zsh-workers@math.gatech.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"ibs8b1.0.NB.yRYVr"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/4076 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu On Jun 9, 9:02pm, Zefram wrote: } Subject: Re: User-defined zle widgets and built-in widget failure } } Bart Schaefer wrote: } >I think I'd rather not have to rewrite my .z* scripts again. How much } >"moving" are we talking about? } } Actually, I don't anticipate permanently removing names established } in 3.0. An option, on by default in zsh mode, would enable the current } names. Those that take the time to rewrite their .z* scripts can then } disable the current names, and get a parameter namespace as clean as } possible. What we need is a way to link variable names to one another, with a few options for how the linkage is accomplished. The options would include having the names share a value, automatic array-to-colon-list conversion (and back), etc. It'd also be useful to be able to define the way that import and export are performed (in which case the imported and exported values might be separate). } If we *don't* introduce a proper namespace scheme, I hate to think what } will happen when modules gain the ability to define special parameters. I don't expect it'd be any worse than the current situation with external programs having to come up with names for their environment variables. If you can explain why a namespace like "zsh." is better than a simple convention like "ZSH_", I'm willing to be persuaded. However, the only reason for introducing naming hierarchy (even if only one level of it as you've so far proposed) is to be able to manipulate entire hierarchies as single entities. If the name of the space is not useful except as a differentiating prefix, then it's better simply to use a prefix. } This is probably a good time to talk about what I've been doing for the } past year. Sounds like a pretty fun job. } three basic aims: } } (1) as little as possible should be built into the base zle module } } (2) built-in widgets should use the same interfaces as } user-defined ones, so that they behave *as if* they were } shell functions } } (3) as much of the ZLE state as possible should be directly } manipulable by user-defined widgets I don't disagree with any of those. However, don't go overboard with (1). An example of a case where I think that idea was carried too far is with the removal of so many of the default compctls in 3.1.4. It seems quite contradictory to me to turn on by default every flashy zle option, but to turn off all the even-more-useful completion defaults. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com