From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-31705-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 9633 invoked by alias); 6 Sep 2013 06:46:39 -0000
Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Workers List <zsh-workers.zsh.org>
List-Post: <mailto:zsh-workers@zsh.org>
List-Help: <mailto:zsh-workers-help@zsh.org>
X-Seq: 31705
Received: (qmail 27495 invoked from network); 6 Sep 2013 06:46:24 -0000
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,
	SPF_HELO_PASS autolearn=ham version=3.3.2
Received-SPF: pass (ns1.primenet.com.au: SPF record at m.gmane.org designates 80.91.229.3 as permitted sender)
X-Injected-Via-Gmane: http://gmane.org/
To: zsh-workers@zsh.org
From: Jan Larres <jan@majutsushi.net>
Subject: Re: Directory completion acts as if CHASE_LINKS is set
Date: Fri, 06 Sep 2013 18:46:03 +1200
Message-ID: <l0btn4$sal$1@ger.gmane.org>
References: <l08meg$v06$1@ger.gmane.org> <130905083139.ZM29859@torch.brasslantern.com>	<l0bbuk$gqp$1@ger.gmane.org> <130905231336.ZM30256@torch.brasslantern.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: yass.opencloud.co.nz
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
In-Reply-To: <130905231336.ZM30256@torch.brasslantern.com>

On 06/09/13 18:13, Bart Schaefer wrote:
> On Sep 6,  1:42pm, Jan Larres wrote:
> } Subject: Re: Directory completion acts as if CHASE_LINKS is set
> }
> } On 06/09/13 03:31, Bart Schaefer wrote:
> } > In any case, this is a problem inherent in the way globbing interprets
> } > "../" -- filename generation does not obey the same rules as "cd" path
> } > resolution.
> }
> } Thanks, that patch does solve the issue with cd to a certain degree. But
> } as you said yourself it is not specific to cd - for example, 'ls ../[TAB]'
> } has the same problem.
>
> No, you misunderstand.  It actually *is* specific to cd -- ls is an
> external command and will physically follow ../, so it is correct for
> completion for ls to do so as well.

Huh, you're right. I never noticed that. That's rather counterintuitive. 
Then I guess cd completion really is the only thing that can be changed. 
Thanks for clarifying!