From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-users-return-20028-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 21042 invoked by alias); 19 Mar 2015 23:18:53 -0000
Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Users List <zsh-users.zsh.org>
List-Post: <mailto:zsh-users@zsh.org>
List-Help: <mailto:zsh-users-help@zsh.org>
X-Seq: 20028
Received: (qmail 1448 invoked from network); 19 Mar 2015 23:18:52 -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=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	daniel.shahaf.name; h=x-sasl-enc:date:from:to:cc:subject
	:message-id:references:mime-version:content-type:in-reply-to; s=
	mesmtp; bh=b+0/yq7RVc28dZHkv47eHyzN9Tc=; b=BsRdgcfdyOMf8FIDa/KyC
	7L+QKqX5L/P05eFj/PM0J2pToV6MoNTGbJqWt171r8UirGEW65DTF0F2LMG930Hq
	jNizJsqt3jtIha/iQ7xeJHSTjmmuqAbbn6XsDM8YitqRqBgrEh4qLI55ctSJPYGD
	zicThFiR+2dPJOBO0sMZnY=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=x-sasl-enc:date:from:to:cc:subject
	:message-id:references:mime-version:content-type:in-reply-to; s=
	smtpout; bh=b+0/yq7RVc28dZHkv47eHyzN9Tc=; b=dhTtrbt0RtSYSOkC1Qie
	9Tk+YlCIe8O3RHXVQ2eVjxkrHfSCaEHPgpGUoi3fdDeyf6LJM1pg5Ihsnues3UVd
	3CvD0mWYmzNziZJftgOFHH8pyJzNH7geM1YMn6Omqe+3IVhJc8ZToU40YDohNdEh
	Z6TtSzx8RT+t3+qkU3D4Wlc=
X-Sasl-enc: uHXzwJefDUavFF9mKKDOe5qWbLc0+HA3Sq24F8QqMLCK 1426807131
Date: Thu, 19 Mar 2015 23:18:49 +0000
From: Daniel Shahaf <d.s@daniel.shahaf.name>
To: Bart Schaefer <schaefer@brasslantern.com>
Cc: zsh-users@zsh.org
Subject: Re: GLOB_COMPLETE and numbered directories
Message-ID: <20150319231849.GD2653@tarsus.local2>
References: <20150319073238.GN3548@tarsus.local2>
 <150319090612.ZM18787@torch.brasslantern.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <150319090612.ZM18787@torch.brasslantern.com>
User-Agent: Mutt/1.5.21 (2010-09-15)

Bart Schaefer wrote on Thu, Mar 19, 2015 at 09:06:12 -0700:
> On Mar 19,  7:32am, Daniel Shahaf wrote:
> } Subject: GLOB_COMPLETE and numbered directories
> }
> } Consider the following:
> } 
> } % mkdir -p {bar,baz}/iota
> } % cat b/i<TAB>
> } [cycles between 'cat ba<CURSOR>/iota', 'cat bar/iota/', 'cat baz/iota/']
> 
> Not what I see here.
> - First tab does ba<C>/iota
> - Second tab shows list of bar/iota baz/iota below ba<C>/iota
> - Third tab begins cycling bar/iota/ and baz/iota/
> 

That's exactly what I see, too.  Sorry for my inaccuracy.

> } % mkdir -p {10a,11a}/iota
> } % cat 1/i<CURSOR>
> } [press <TAB>]
> } % cat 1<CURSOR>a/iota
> } [press <TAB>]
> } % cat 1a/iota<CURSOR>
> } [stays the same upon pressing TAB]
> } 
> } I expected the second <TAB> press to offer me the possible completions
> } '10a' '11a'.
> 
> With only glob_complete, it works by appending a * to the end of the word,
> not by inserting a * at the cursor position.  1a*/iota* doesn't match
> anything.
> 
> Any time the cursor is left in the middle of a word, it means that the
> completion system is waiting for you to type a disambiguating character.
> 

Okay.

> } I'd at least like not to be left with "1a/iota<CURSOR>"
> 
> It's supposed to be sufficient to "setopt completeinword" to get the
> behavior you want, and indeed it works if I literally type out
> 
> % cat 1a/iota
> 
> and then move the cursor to 1<C>a/iota before pressing TAB.

It seems to work if I use <Left-arrow> to move the cursor, but not if
I use <M-b> to move the cursor.  Details:

If I type "cat 1a/iota<Left><Left><Left><Left><Left><Left><TAB>", I get
"10a/iota" and "11a/iota" offered below the input line (as in the second
<TAB> press in your description).

However, if I type "cat 1a/iota<M-b><Left><Left><TAB>", nothing happens,
even if I press <TAB> a few more times.

This is in XTerm(278) with TERM=xterm on Debian.  I invoked xterm as
   xterm -xrm 'XTerm*eightBitInput: false'
.  Without that resource, it behaves the same way except <Esc><b> is
required instead of <M-b>.

> However,
> for some reason this doesn't happen when "continuing an in-progress
> completion" with a second TAB.  I believe that's because the second
> tab just regenerates the listing with the same pattern as on the
> first tab, and that's not sufficient to disambiguate.

Okay.  Any pointers on how to get started on a fix?  I tried to have
a look at the code, starting with expandoncomplete() (the C function),
but got lost.

Thanks,

Daniel