From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22440 invoked from network); 5 Nov 1999 15:40:52 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 5 Nov 1999 15:40:52 -0000 Received: (qmail 26163 invoked by alias); 5 Nov 1999 15:40:47 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8572 Received: (qmail 26156 invoked from network); 5 Nov 1999 15:40:47 -0000 Date: Fri, 5 Nov 1999 16:40:45 +0100 (MET) Message-Id: <199911051540.QAA11367@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Oliver Kiddle's message of Fri, 05 Nov 1999 14:54:28 +0000 Subject: Re: completion grouping Oliver Kiddle wrote: > ... > > I may not have properly understood your tags and priority system but I'm > not convinced that it is worth the extra complexity in the completion > functions to be able to configure the order that different groups are > completed. Could the system use the groups specified with compadd -V / > -J? Also, could the system be done so that for example, _jobs would call > _tags to say it is generating jobs as opposed to every completion > function which calls _jobs. Basically, what I'm saying, is can we reduce > the extra complexity that it adds to the functions. The quick answer is: No. Currently, the amount of work needed to make a functionm use tags is: - for a function/context that completes only one type of matches: local tags _tags -i || return 1 that's all. Currently this can only be used by users to say if they want any matches at all or not, so it isn't really useful. But I'd like to make sure we use it everywhere so that if we once add the online-documentation stuff we already have the needed calls everywhere. - for functions adding multiple types of matches: local tags _tags while _tags; do if [[ "$tags" = ... ]]; then ...; fi if [[ "$tags" = ... ]]; then ...; fi ... [[ ]] && break done (or some other tests on "$tags"). And because of this we can't move that code into the helper functions like `_jobs': only the calling function (e.g. `_kill') knows what different types of matches can be generated and thus knows if there are other tags to try if one failed. But, again: completion functions without that will work as before, so users writing their own little functions don't really have to worry about all this. Only if they want them to be included in an official release it would be nice if they use/supply/support everything the completion system offers. But in most cases it shouldn't be too hard for one of us to add that code to functions we get (if we get any at all). > ... > > > So, like Bart I'd really like to have things stabilize. The tags- and > > config- stuff is partly meant as a final cleanup (partly; the other > > part is to add a missing bit I should have thought about from the > > I'd also agree on the stability point. If we get a 4.0 out, we might > also get some feedback from more normal users. I'm trying to enforce this discussion because I don't like the thought that we hurry to get 4.0 out of the door and later decide (based on our experience or user requests) that it would be nice to make things better configurable. It may well be that this would require changing the way things are configured and user would have to change their setup in the release-after-the-next-one. I only want to make sure that we release it in a form that allows us to enhance it without making user setups invalid. > ... > > I found the system quite hard to understand initially. There are a > number of points I've never really understood properly, like the > differences between the different types of prefix/suffix or whats going > on with some of the functions which handle menu-completion. I've mostly > found it quite easy to write a completion which basically works but I'm > never very sure that it is totally correct. Basically I'd say that if they do what you want, they are correct. The only thing that I missed from some of the functions submitted were the calls to `_description'. Currently that's the only thing one really has to remember -- and if you use one of the helper functions like `_arguments' this should be forced (although in some cases it would be nice if people weren't so lazy to omit the option-descriptions -- but I've done that myself already, so I better not complain too loudly; ahem). > In many ways I find it > easier than the old compctls. I always found compctls to be very hard to > read compared to tcsh completes and tended to need the manual next to me > for constant reference on the option names which was annoying. > > The main things which I would want to configure with the new completions > is often how the completions are listed and when. For example, I don't > like the job completion after bart-8 which completes by the job number > rather than the name of the command: > % will list, for e.g.: > > [ 1] man less > [ 2] less config.h > > And will complete to %1 or %2. I think it should return to completing > the commands after '%' or a config key should select. I did that because I once had the case where two jobs started with the same word (and I really hate getting `%foo\ really\ long\ argument\ list'). > I also don't like > that kill will complete job names straight-away as opposed to only after > an inital '%'. It seems a bit weird when a job gets listed twice - once > as the job and once in the ps listing. Jobs aren't only just processes, but this is *exactly* what we (at least I, and I think Peter, too) want to achieve with this priority mechanism. You don't like it, so you should have a way to say that you want to see jobs only after a `%' or that you first want pids and if there is no match, fall back on jobs. That's also why I immediately changed the config keys for the option/argument stuff into tags -- there we had it already and I want to make it easier/generic/less-ad-hoc to be able to specify this in more places. Your request to get names instead of job numbers, btw, fits nicely into the style-mechanism I want to have (it's comparable to the describe- options stuff). > In a few cases I've found that other people's completions have taken the > approach of completing everything which is valid in a particular context > whereas I prefer to keep the number of matches down to a minimum, for > example, by only completing options after an initial '-' and jobs after > a '%'. This is the main sort of thing which I think should be > configurable. See above. > As an aside, we seem to have a few cases where we complete to a numbered > list: > cd ~+ > cd - > cd $path[ > fg % > are all examples, yet we aren't very consistent in how we display the > numbers: > '[ 1] ', '1 -- ', '1) ' are all used. Maybe this format should be > configurable. In one of my last patches I changed the job-list to use ` -- ', too. I was first comparing it to the output of `jobs'. The `1)' is in the subscript code, right? Yes, we should change that. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de