From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13137 invoked from network); 15 Dec 1999 08:25:03 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 15 Dec 1999 08:25:03 -0000 Received: (qmail 9493 invoked by alias); 15 Dec 1999 08:24:42 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 9052 Received: (qmail 9486 invoked from network); 15 Dec 1999 08:24:41 -0000 Date: Wed, 15 Dec 1999 09:24:39 +0100 (MET) Message-Id: <199912150824.JAA03740@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Peter Stephenson's message of Tue, 14 Dec 1999 23:46:41 +0000 Subject: Re: Namespaces again (was: RE: PATCH: Add jobdirs association to parameter module) Peter Stephenson wrote: > Sven Wischnowsky wrote: > > - What exactly would we gain by using different tables? > > It's really an internal matter. If you can give the same impression easily > without that's probably OK. > > > - In which way would they remain `invalid'? Especially from a user's > > point of view -- who should still be able to say `.a.b=c'. > > I think Andrej was saying ${a.b} should be invalid, which I agree with > since otherwise it complicates things mightily --- i.e, if there are any > dots in a name, there must be one at the beginning. Just allowing > `.' separators might be enough for testing, but it's too much of a hack for > normal use. Ah, I see. Yes, that sounds reasonable. > Unfortunately, catching all the relevant entry points to the > parameter code to test this sort of thing tends to be rather a nuisance. Indeed. > It would be nice to get the full module name into the namespace, but > perhaps ${.parameter.options} is a bit long. I've been thinking some more... maybe we should only use it for logical grouping. E.g. the parameters from zle ($BUFFER etc.) should be $.zle.buffer etc. and the ones from the zleparameter module should use the same prefix ($.zle.keymaps seems to make a lot more sense to me than $.zleparam.keymaps or even $.zleparameter.keymap). And then the parameter module could probably use `$.zsh.' as the prefix. I think the result would be that the names say what they give access to instead of saying where they come from - and I hope user's will find this much less confusing. > I think it's still early enough days with the parameter module to make this > change without too many people throwing themselves off millennial > landmarks. We should decide if others need it. mapfile is perhaps the > only candidate, but then ${.mapfile.what?}, or can we get away with > ${.mapfile} ? Then there is the question how far we want to go. E.g. should we change $BUFFER and friends? The special completion parameters like $.comp.state, $.comp.prefix and so on? Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de