From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10513 invoked from network); 12 Feb 2003 12:29:20 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 12 Feb 2003 12:29:20 -0000 Received: (qmail 16401 invoked by alias); 12 Feb 2003 12:29:09 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 18229 Received: (qmail 16394 invoked from network); 12 Feb 2003 12:29:09 -0000 Received: from localhost (HELO sunsite.dk) (127.0.0.1) by localhost with SMTP; 12 Feb 2003 12:29:09 -0000 X-MessageWall-Score: 0 (sunsite.dk) Received: from [62.189.183.235] by sunsite.dk (MessageWall 1.0.8) with SMTP; 12 Feb 2003 12:29:9 -0000 Received: from exchange01.csr.com (unverified) by (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 12 Feb 2003 12:35:46 +0000 Received: from csr.com (tinky-winky.csr.com [192.168.144.127]) by exchange01.csr.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id DQ47MK4J; Wed, 12 Feb 2003 12:29:47 -0000 To: zsh-workers@sunsite.dk (Zsh hackers list) Subject: _path_files prefix handling Date: Wed, 12 Feb 2003 12:29:10 +0000 Message-ID: <19754.1045052950@csr.com> From: Peter Stephenson There's a general problem with _path_files which we've encountered before and fixed with specifics (e.g. the fake style), but actually needs fixing generally. If I want to complete /some/path/to/a/dir/, then any failed component in the directory path will stop me completing, even if the full component /some/path/to/a/dir/ is found and has entirely standard Unix behaviour. We encountered this in Cygwin, but it occurs in ClearCase too: /view/pws/vob/bcsw_test/bc/dev/src/csr/lc/radiosched_data.c@@/main/ behaves like an ordinary directory, but there is no radiosched_data.c@@ in the directory list for lc --- even though [[ -d /radiosched_data.c@@ ]] returns true. This is looking to me increasingly like an intrinsic limitation of the completion system. I can see two ways out. 1. At the least we could test [[ -d pathcomponent ]] at each stage and trust the system to get this right, rather than rely on pathcomponent appearing in the list of entries in the current directory. This ought to be relatively simple, and I think fixes all the problems I know about --- this test works for all components of /cygdrive/c/Program\ Files under Cygwin, for example, making half of `fake's properties redundant (you still need it to be offered the choice, but don't need it for the system to recognise that the choice is a valid path component). 2. Probably unnecessary now 1. has occurred to me, but a large fraction of the time with a long path you simply want to complete the last component. This could presumably be optimised along the lines of if [[ -d ${PREFIX:h} ]] then ... as a style, possibly set by default. Presumably involves more invasive surgery than the first option, but I'd very much like to see one of the two implemented. _path_files is fairly complicated, but I suspect 1. could be done without more than a modicum of frustration. -- Peter Stephenson Software Engineer CSR Ltd., Science Park, Milton Road, Cambridge, CB4 0WH, UK Tel: +44 (0)1223 692070 ********************************************************************** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. **********************************************************************