From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16575 invoked from network); 17 Sep 1999 09:43:56 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 17 Sep 1999 09:43:56 -0000 Received: (qmail 13115 invoked by alias); 17 Sep 1999 09:43:44 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 7905 Received: (qmail 13108 invoked from network); 17 Sep 1999 09:43:44 -0000 Date: Fri, 17 Sep 1999 11:43:42 +0200 (MET DST) Message-Id: <199909170943.LAA02274@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Sven Wischnowsky's message of Fri, 17 Sep 1999 11:29:49 +0200 (MET DST) Subject: Re: PATCH: _cd I wrote: > This discussion about `don't always include the directoies from > cdpath' made me think that this probably should be configurable in the > new system. I haven't done that yet, though, because maybe this could > be done together with the other changes for `_files' (using the same > config key, I mean). And btw. this config key (`path_merge_*' or > whatever) should probably allow to define this on a per-command and/or > per-pattern basis. Which almost looks like a task for an array or > association. Hm. I've just stepped back some more... Some time ago we had some people here asking if it were possible to see first only, say, `*.tar' files and then hit some to to get the directories. Now we have this discussion about showing options or not. Why not combine them? What I'm thinking about is a combination of a completer that would be stuck in front of the `completer' key and uses some config keys and/or parameters/arrays/whatevers to set up some completion-system-global parameter(s). These are then used by all completion functions concerned to find out which matches should be generated (and how, thinking about descriptions). And with (an improved (and renamed) version of) `_verbose_list' one could get this `first-this-and-then-that' behaviour. This is big (quite some work), but if done well, should hopefully keep us from more such requests (or simplify implementing them). We'll need some more discussion about this, though. Or maybe people are already fed up with increasing complexity. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de