From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5165 invoked from network); 25 Feb 1999 15:04:48 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 25 Feb 1999 15:04:48 -0000 Received: (qmail 4702 invoked by alias); 25 Feb 1999 15:03:44 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 5528 Received: (qmail 4681 invoked from network); 25 Feb 1999 15:03:42 -0000 Date: Thu, 25 Feb 1999 16:02:57 +0100 (MET) Message-Id: <199902251502.QAA29772@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Andrej Borsenkow"'s message of Thu, 25 Feb 1999 16:32:26 +0300 Subject: RE: change to __path_files and clean up of Functions/Completion needed Andrej Borsenkow wrote: > > > I think, it is unacceptable. It is the same, as if users had to modify C > > > sources to change compctl behaviour. > > > > I don't think so. This is shell code after all. > > O.K. I hope it is not too late. Certainly not, we are far from a final version and it is mails like this one that tells the more development-oriented of us what other would like to have. > The good old completion has some nice features: > > 1. It works out-of-the-box. Not setup is needed; immediately after > installing zsh users can start with compctl. It's a shift of means, yes. Instead of a builtin you use functions. > 2. it is easy to modify completion on-the-fly. What is important, it is the > same command with the same syntax as used in startup files. It is > invariant - 'compctl $(compctl -L cd) cd' is noop as it should be. There are the `def*comp' functions and defining completion functions on-the-fly isn't that complicated (and unusual) either (at least I though that...). We probably should merge the `def*comp' functions into `compdef' with options for defining pattern/key completion functions and give it an option to delete definitions, btw. > 3. it is easy to use. It is not a joke. Using compctl amounts simply to > listing what is considered a match - no shell programming is needed. It can > be used immediately after reading manual. (Please, I know about -K. But most > cases are actually quite simple). What's more important, no shell > porgramming is needed for extended/conditional completion. All is limited to > a single command. I had the impression that some think `compctl -x' is more complicated than shell programming. Do not look to much at the things currently needed, things will improve over time. > 4. (this is of more personal nature) It does not pollute namespace (why > don't we have anonymous functions :) It does not suddenly defines > variables/functions/aliases that a completion user is not interested in at > all (and probably, should not know of as well) Not fully to the mark, but: the aliases will almost certainly disappear in one of the next versions (at least I'm planning to remove them when we have the new test-syntax). Also, the global parameters should probably be changed to `_comps' and `_patcomps', reducing the probability of name clashes. > I think, it is time to decide, if we want new style completion be for > wizards only or intended for general user community. If it should be of > general use, it should be at least as easy to use, as compctl. Exactly for > these reasons my first reaction was to stay with compctl as a single entry > point and use new style completion to extend it's ability. I'd like to think the other way round: use `compctl' if you like it and it is enough for you. If yo don't like it or you have a problem you can't (easily) solve there, use the new completion stuff. And the Functions/Completion we currently have are *only examples*. You can easily write a completion widget that does: complete() { case "$COMMAND" in foo) ...complicated stuff for comamnd foo...;; ... probably for other commands ... *) compcall;; # use compctl elsewhere esac } Something like this will eventually appear as an example in the manual, I think. The examples we currently have began with my attempt to show that everything `compctl' does can be done with the stuff I implemented (actually, I wanted to show that already more is possible, `_path_files' for example). This, btw, is also the reason why I still don't like calling completion widgets from `compctl'. If once `compctl' isn't enough any more, use completion widgets. Implementing a simple one is easy and you can still use your old `compctl's with `compcall' -- no real need to make this two-way. > What I suggest, is some framework that IMHO makes new completion almost as > easy to use as compctl. > > 1. use separate array (cpath?) for a completion stuff. Mixing it with fpath > is probably a bad idea (at least, I suddenly get a bunch of autoloaded > functions that actually dont exist :) If you mean: another builtin path parameter I'm against it. I want the user to be completely free in what kind of completion code he wants to implement and I don't even want to direct his thinking into a certain direction by such a parameter. If you mean that `cpath' should be used only in shell code, I would be for it but I would want to have the functions autoloaded -- and for this we need `fpath' (again: this could be solved if `autoload foo=' would work). > 2. automatically install at least run-time for new completion (and probably > the completion for zsh builtins) in standard system-wide location and > initialize cpath to point to this location Again, I want the users to decide what kind of completion function he'd like to use, so we can't pre-install something, especially not with cpath which the user probably doesn't need. > 3. provide a single command to make life easier (compctl is taken, sigh) > This command would need at least > > init - initialize completion. Traverse cpath loading > definitions. This would allow users to > override system-wide completion by adding own > directories to cpath after system location > > load - load a (single) definition. With options to read > from stdio, single file or a directory. And may be > directly as argument. Great for testing :) > > dump - printout of current definition(s) for selected command(s) > (--default-- etc). This should be directly usable as input > to load. 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. 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. > 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 moved this into the `_match_*' functions to make it usable for all functions doing matching. But as a side effect this also saves users from the shock they may get when seeing functions like `_path_files'. We should probably add comments in `init' pointing to the places where the user might wish to look at (as Peter did with `dump', hm, so it was only me who forgot to do this, oops). > 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. 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'. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de