From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 688 invoked from network); 25 Feb 1999 16:58:09 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 25 Feb 1999 16:58:09 -0000 Received: (qmail 17029 invoked by alias); 25 Feb 1999 16:57:54 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 5530 Received: (qmail 17020 invoked from network); 25 Feb 1999 16:57:52 -0000 Message-Id: <9902251642.AA70773@ibmth.df.unipi.it> To: zsh-workers@sunsite.auc.dk Subject: completion cleanup discussion + patch In-Reply-To: "Sven Wischnowsky"'s message of "Thu, 25 Feb 1999 16:02:57 NFT." <199902251502.QAA29772@beta.informatik.hu-berlin.de> Date: Thu, 25 Feb 1999 17:42:03 +0100 From: Peter Stephenson (I hope my comments have kept pace with the changes, I've been editing furiously as new stuff arrives...) > I would want to have the > functions autoloaded -- and for this we need `fpath' (again: this > could be solved if `autoload foo=' would work). Not entirely, since currently init searches the autoload directories for completion definitions. One possibility is simply for init to assume that its own directory is where the functions are, and add that to the front of fpath if it's not there. If the namespace problem is really bad we can implement Bart's special _* suggestion, perhaps as a shell option. I also quite like the flexibility of the function mechanism for completions. > Once we renamed `init' and `dump' to `compinit' and `compdump' (what > Peter probably will do in pws-10 -- at least we already talked about > it) and if we have only one function for defining them (`compdef'), we > have almost reached the state you described. I was going to say what I was thinking of doing. The way the files are sorted into directories may want changing. init -> compinit dump -> compdump Make three directories under Functions/Completion, containing Core: stuff the user will need and probably won't want to touch: compinit, compdump, _files, _path_files, _main_complete, _normal Base: stuff the user will probably want, but doesn't need or may want to edit: _default, _match_pattern, _match_test, _subscript, _precommand; maybe some of the more basic functions like _setopt, maybe even _cd, any offers? User: `lucky dip' for everything else. Probably a README in the top level directory would be a nice touch when things get settled down. While I remember: init and dump miscount the number of files which are to be loaded when there are ones with the same name in different directories, e.g. if there is a personalised _default as well as a system wide one it thinks there are two different files to load, whereas only one will be found. This isn't as bad as I first though since init and dump count the same way (though I could have sworn I was getting too many dumps at one point), but anyway the patch below uses typeset -U and the basename of the file so it should get the count right (except that . isn't ignored in fpath). > Putting everything into > one function isn't really needed, is it? Especially since dumping > won't be done that often (but adding a function that calls/sources > `init', `dump', and `compdef' depending on the options it gets would > be easy). But then again: this would be an improvement affecting (and > intersting for) only the the current example. I'd have thought it would be OK just to have one init file that gets sourced at the start, and then one command for management (e.g. the extended compdef). compdef should probably also let you see how things are defined, so that the user doesn't need to look at the arrays directly. I don't think having compinit as a function is a good idea, even apart from the typeset's having local effect (I could write a flag not to make the variable local, now I've neatened bin_typeset() up marginally), since you only need to run it once and it takes up memory for the whole session. > > 4. The run-time for completion stuff should _not_ require > > modification. Even more so, because these functions are very close to > > winners of Obfuscated Zsh Programming Contest :-) > > You mean the `-M' problem, right? I agree the run-time stuff shouldn't *need* modification, but that's already the case. It's a slight worry that defining matchers is different for _path_files, so _match_pattern is probably destined to be slightly strange, though there are comments on how it should work (I have to admit I've only vaguely registered what's going on there). > > This command should behave as function (or be implemented as such). This > > allows to start with emulate -RL zsh, set all needed options (extendedglob > > problem :), define any needed local variables without fear to stomp on > > user's environment. Anything, that this function exports, should 'course be > > documented. > > The examples need global parameters to keep the state that has to live > longer than the execution of the function. If we had parameter > namespaces, we could cleanly solve this (ksh has them, should we...), > and we could solve it in a way that will not collide with any > parameters used by anyone. (Since then we have underlines in front of comps and patcomps). I don't think parameter namespaces would be too hard to implement; just keep paramtab in another hash table, but I don't have a version of ksh that does this. There are actually only four or so variables used (apart from specials, which are local to completion functions and don't clash with the use of the same variable outside). > As to the documentation, if been thinking about this -- the question > is: where should we document it? Certainly not in the manual, since > these are only example functions like `zls'. This is part of a wider problem, which Andrej mentioned, about installation. There should at least be an install target for this, though I suppose people won't want it done with a basic install. In that case we need to arrange so that simply sourcing one file will set up all the stuff that has been installed; maybe a configure option could pick 'core', 'basic' or 'all' to choose how much to install in a single target directory, then an $fpath check in compinit would do the trick. Then we could have a separate manual for the standard function suite which gets installed with all this stuff I was thinking about a similar mechanism for the zftp functions, so similarly I would write one for the zftp function suite and install those together if requested. We would definitely need wider feedback from potential installers to get this right. --- Functions/Completion/dump.bk Thu Feb 25 17:23:03 1999 +++ Functions/Completion/dump Thu Feb 25 17:33:58 1999 @@ -16,7 +16,8 @@ _d_file=${COMPDUMP-${0:h}/init.dump} -_d_files=( ${^~fpath}/_*~*~(N) ) +typeset -U _d_files +_d_files=( ${^~fpath}/_*~*~(N:t) ) print "#files: $#_d_files" > $_d_file --- Functions/Completion/init.bk Thu Feb 25 17:23:03 1999 +++ Functions/Completion/init Thu Feb 25 17:33:56 1999 @@ -211,7 +211,8 @@ setopt extendedglob fi -_i_files=( ${^~fpath}/_*~*~(N) ) +typeset -U _i_files +_i_files=( ${^~fpath}/_*~*~(N:t) ) _i_initname=$0 _i_done='' -- Peter Stephenson Tel: +39 050 844536 WWW: http://www.ifh.de/~pws/ Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy