From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6121 invoked from network); 29 Feb 2000 11:42:21 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 29 Feb 2000 11:42:21 -0000 Received: (qmail 15376 invoked by alias); 29 Feb 2000 11:42:04 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 9930 Received: (qmail 15360 invoked from network); 29 Feb 2000 11:42:04 -0000 Date: Tue, 29 Feb 2000 12:42:00 +0100 (MET) Message-Id: <200002291142.MAA08657@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Tue, 29 Feb 2000 08:21:35 +0000 Subject: Re: Precompiled wordcode zsh functions Bart Schaefer wrote: > On Feb 29, 8:45am, Sven Wischnowsky wrote: > } Subject: Re: Precompiled wordcode zsh functions > } > } [...] In my implementation digest files are really only one-file- > } directories. I.e. they are searched like normal directories by > } getfpfunc() (more precisely a utility function used by it). It will > } not define all functions in the digest file immediately. I really > } prefer that behaviour because a user has to worry about nothing when, > } for example, he wants to override one of the functions with his own > } definition in a directory earlier in $fpath. > > I'm concerned that we should at least have a way to produce a warning > about it. I mean, if I were to invent a function named `_files' that > had nothing to do with completion, and put it in a directory early in > my $fpath -- even PWS's guide recommends putting your own functions > before distributed ones -- three-quarters of the completion system > would be mysteriously broken for me. If the whole completion system > has been hidden inside one giant file, how do I find out what has gone > wrong? That's one of the reasons why I'm not too happy with the thought of installing such a digest file per-default. I mean, maybe we should just leave it to the user to create his/her own digest files containing the stuff (s)he really wants. The 400KB (yes, it's 400, the 300 was a typo, sorry) isn't that much, is it? With that we would have the same situation as now. Also, the functions in the digest can, of course, be listed, so it's the same problem as looking into the directories in $fpath. Hm, maybe a function that checks everything in $fpath to see which names are defined more than once? [1] > And lest you think this is farfetched, please note that I've had the > following in my .zshenv for many years now[*]: > > alias calc="noglob _calc" > _calc() { awk "BEGIN {print $*}" < /dev/null } > > So existing user functions with leading underscores are not out of the > question. I had functions beginning with an underscore myself... > Oh, and what's the handling with respect to kshautoload vs. a function > like _cvs that wants to define other functions and then call itself? Currently zcompile just puts the contents of the files into the wordcode files. I.e. functions in them behave exactly like the files. Bye Sven [1] There are other interesting possibilities for functions wrt compilation: a `recompile' function that checks file dates and digest files. A function for syntax-checking a file -- that's possible because the zcompile reports parse errors as usual and one can use /dev/null as the name of the target wordcode file. -- Sven Wischnowsky wischnow@informatik.hu-berlin.de