From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6376 invoked from network); 10 Mar 1999 16:23:04 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 10 Mar 1999 16:23:04 -0000 Received: (qmail 551 invoked by alias); 10 Mar 1999 16:22:16 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 5733 Received: (qmail 540 invoked from network); 10 Mar 1999 16:22:12 -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: <14054.39908.412334.475356@awayteam.zanshin.com> Date: Wed, 10 Mar 1999 08:20:52 -0800 (PST) To: Sven Wischnowsky Cc: zsh-workers@sunsite.auc.dk Subject: Re: PATCH: tricky.c (was messages from Andrej and Bart) In-Reply-To: <199903100925.KAA16215@beta.informatik.hu-berlin.de> References: <199903100925.KAA16215@beta.informatik.hu-berlin.de> X-Mailer: VM 6.68a under Emacs 20.3.5.1 Reply-To: Bart Schaefer Sven Wischnowsky writes: > > Bart Schaefer wrote: > > > Using 3.1.5-pws-11 with the patches Sven posted overnight (well, overnight > > US Pacific Time) 3/8-3/9, I get this strange behavior: > > > > zsh% fpath=($PWD:h > > zsh% fpath=(src/ > > > > I expected to get "fpath=(/home/schaefer/src/" ... > > That one is a poser... `expand-or-complete' never expanded this > without braces. Ah ... you're right. That would actually be fine, too (keep the old behavior of it simply feeping on the above input); but it's completely wrong to have it replace the input with a fragment of the parameter's value. > If it expanded it, it wouldn't add a trailing slash > (but instead add a space, try `${PWD:h}'). Yes, I know. > So this is handled by the completion code. There, it expands the > `$PWD:h', gets a path from it, and then tries to complete the last > pathname component. Yes, but there isn't anything to which that last component should have completed (there was no subdirectory "src" of the current directory). > The problem is that after expansion, the code can't find out > what came from the expansion in cases like `${foo}x'. Hrm ... so what was happening in the old completion code in this case? > So the patch just uses the expanded prefix if it has the problem that > the expanded prefix contains slashes and the original string doesn't. > Maybe a better solution would be to do nothing in such cases. Does this apply only to file completion? What if the expansion happens in some other context where slashes aren't special?