From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19921 invoked from network); 27 Oct 1999 08:45:16 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 27 Oct 1999 08:45:16 -0000 Received: (qmail 28209 invoked by alias); 27 Oct 1999 08:44:46 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8440 Received: (qmail 28199 invoked from network); 27 Oct 1999 08:44:26 -0000 Date: Wed, 27 Oct 1999 10:42:32 +0200 (MET DST) Message-Id: <199910270842.KAA16188@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Tue, 26 Oct 1999 17:17:16 +0000 Subject: Re: PATCH: completion Bart Schaefer wrote: > ... > > Which also means "compiled in to static builds". Did you try a static > build? I guess I'll find out soon enough. I tried it with a fully dynamic shell and a dynamic-enabled shell but with `complete' linked in and then once with `compctl' loaded dynamically and once with `compctl' linked in. > ... > > } - Since this was asked by Bart: yes, I made `functions' show disabled > } functions, too. I think this is right because `functions' should > } show the contents of the functions hash table. > > I don't think I agree with this. The purpose of "functions" is not just > to dump the hash table; it's for user information. If a function has > been disabled for some reason, it shouldn't be shown: "disable" is among > other things a sysadmin tool for concealing things that certain users > should not see. > > Which, incidentally, makes me think of something I hadn't before: If a > sysadmin wanted to prevent users from changing the completion setup in > the old system, he could simply "disable compctl" in /etc/zshenv. Now, > there's no way to lock in a fixed set of completion functions. > > Do we need to be able to mark functions read-only, as can be done with > parameters? Interesting, hadn't thought about that... > ... > > } However, the way they > } are currently represented (with the `' prefix) is not nice > } and I'd like to hear if anyone can think of something better. > > "Not nice" doesn't even begin to cover it: `eval "$(functions myfunc)"' > might read from a file named "disabled" and write it to "myfunc"! No, the output of `functions' isn't changed (of course). > } Maybe we should just add a `disabled' parameter containing all > } disabled functions, aliases, etc. > > Can't do that without disambiguating somehow -- you could have an alias, > a function and a command all named "foo" all of which are disabled. > However, this is probably the best way to go. That's why I also suggested splitting them into pairs: `functions' and `disabledfunctions' (or `disfunctions' or something like that). I already came to the conclusion that this is probably the way to go. It will also make some completion functions simpler. > } - For the `userdirs' parameter I move the fast YP/NIS code into > } `hashtable.c' (where the fill-table-function used `getpwent()'). > > There was already too much stuff in hashtable.c, IMO ... it'd be nice > to have one file that is the hash table implementation, and one or more > others that create each of the hash table instances. Right. It irritated me a lot when I found such code in that file. > ... > > I don't think it's "too late," but I don't have a strong opinion either > way on whether to add a prefix. Given that they're all now "hidden" by > default, so that they won't conflict with locals declared in e.g. ksh > functions, I don't think it's as big a deal, and the consistency with > e.g. $signals (for which it _is_ too late) is nice. > > On the other hand, reducing collisions is probably a good thing too. ;-) Don't go to the elves for advice... > } If you load the parameter module in your `.zshrc', you'll notice that > } `compinit' now loads `parameter' and `zleparameter'. Without `compgen' > } we need it in too many places to get away without it. And now the same > } question as for the `computil' module: should we make them be > } automatically autoloaded (and linked in for static shells) > > Yes! If the stock set of completion functions are useless without them, > they have to be linked into static shells. However, it would be nice if > they weren't actually "loaded" in the zmodload sense until they were > needed, even in a static shell. That's going to require some changes to > the way zmodload and static modules work. Right. Hadn't thought about that either. But in a fully static shell, wouldn't it a bit surprising when, for example, parameters just appear because they are used (because they were `autoloaded')? Anyway, the patch at least makes the parameter modules autoloaded. Bye Sven diff -u oldsrc/xmods.conf Src/xmods.conf --- oldsrc/xmods.conf Wed Oct 27 10:38:17 1999 +++ Src/xmods.conf Wed Oct 27 10:39:01 1999 @@ -5,3 +5,5 @@ sched complist computil +parameter +zleparameter diff -u oldcompletion/Core/compinit Completion/Core/compinit --- oldcompletion/Core/compinit Tue Oct 26 13:12:03 1999 +++ Completion/Core/compinit Wed Oct 27 10:39:37 1999 @@ -78,10 +78,6 @@ fi done -# We need the parameter modules. - -zmodload -i parameter zleparameter - # The associative array containing the definitions for the commands. # Definitions for patterns will be stored in the normal arrays `_patcomps' # and `_postpatcomps'. diff -u olddoc/Zsh/compsys.yo Doc/Zsh/compsys.yo --- olddoc/Zsh/compsys.yo Tue Oct 26 13:11:30 1999 +++ Doc/Zsh/compsys.yo Wed Oct 27 10:42:03 1999 @@ -23,10 +23,6 @@ ifnzman(noderef(Matching Control)) for further details. -Also note that this completion system requires the tt(parameter) and -tt(zleparameter) modules to be linked into the shell or to be -dynamically loadable. - startmenu() menu(Initialization) menu(Control Functions) -- Sven Wischnowsky wischnow@informatik.hu-berlin.de