From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3231 invoked from network); 26 Feb 1999 06:44:37 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 26 Feb 1999 06:44:37 -0000 Received: (qmail 23781 invoked by alias); 26 Feb 1999 06:44:18 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 5536 Received: (qmail 23771 invoked from network); 26 Feb 1999 06:44:14 -0000 X-Authentication-Warning: awayteam.zanshin.com: schaefer set sender to schaefer@tiny.zanshin.com using -f From: Bart Schaefer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14038.16793.21753.668052@c-bart.amazon.com> Date: Thu, 25 Feb 1999 22:39:21 -0800 (PST) To: "Andrej Borsenkow" , Sven Wischnowsky , Peter Stephenson Cc: Subject: Re: completion cleanup discussion In-Reply-To: <001301be60c3$48911730$21c9ca95@mowp.siemens.ru> References: <199902251502.QAA29772@beta.informatik.hu-berlin.de> <9902251642.AA70773@ibmth.df.unipi.it> <199902231026.LAA24103@beta.informatik.hu-berlin.de> <001301be60c3$48911730$21c9ca95@mowp.siemens.ru> X-Mailer: VM 6.65a under Emacs 20.3.5.1 Reply-To: Bart Schaefer Andrej Borsenkow writes: > > 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. One of the things that STILL annoys me about 3.1.2+ is that all the default compctl settings are gone. Completion of anything but files is entirely useless "out of the box." > 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. > > 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. I don't think anyone is proposing removing the simple compctl options. Even the complex `compctl -x ...` bits will hang around until the new stuff has been through at least one "official" "production" release, I expect. > 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 I disagree. However, perhaps the `autoload` commands for the completion function names could be delayed until nearer the time they're needed. > 2. automatically install at least run-time for new completion (and > probably the completion for zsh builtins) in standard system-wide > location I've long thought that copying the Functions/ subdir to somewhere in the configure-selected $(libdir) would be a good idea, regardless of the new completion code. I always do so manually when I install zsh myself. As for enabling default completions, no argument from me; see rant above. > 3. provide a single command to make life easier Given (2), I think it's fine for this to be a shell function rather than a builtin. Perhaps the init function needs to go in the "regular" fpath and all the auxiliary functions into subdirs that aren't added to fpath until the init function runs. > 4. The run-time for completion stuff should _not_ require modification. This would be ideal, but ... look at Misc/compctl-examples. There are in some cases two or three ways to get not-quite-identical completions in different circumstances. Further, there are lots of minor differences in things like completion of command arguments (how many variants of tar, find, dd and ls are there?) that require tweaking on different platforms or even different installations of supposedly the same platform. A better goal should be that the completion run-time should be easy to modify when necessary -- which was the intent of moving it into shell functions in the first place. Sven Wischnowsky writes: > > I think, it is time to decide, if we want new style completion be for > > wizards only or intended for general user community. > > 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. > > This, btw, is also the reason why I still don't like calling > completion widgets from `compctl'. If I want to use exactly one completion for which there already happens to be a widget implementation, why should I have to redo all my key bindings and load other extra functions and dispatch-table arrays just to get at it? If we're working out all these complex widget functions, they at least should be maximally re-usable. Seriously, although I instigated this whole effort, it remains the case that 98% of my own completion needs are covered by simple compctls. If I want to complete something fancier, say cvs, I use ESC-q to push the current command line, then run an autoloaded shell function that installs my set of `compctl -x ...` commands, and then I finish completing when zle pops the buffer stack at the next prompt. > 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...), What do ksh parameter namespaces look like, syntactically? > 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'. Why not in the manual? The Perl manual has sections that are entirely dedicated to "template" implementations of various Perl idioms. If we do arrange for installation in $(libdir) of the Functions/ directory, there's no reason not to treat it as a real part of zsh and have a manual section devoted to it.