From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26518 invoked by alias); 12 Feb 2011 23:03:47 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 28752 Received: (qmail 27154 invoked from network); 12 Feb 2011 23:03:45 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) 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 autolearn=ham version=3.3.1 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <110212150335.ZM2771@torch.brasslantern.com> Date: Sat, 12 Feb 2011 15:03:35 -0800 In-reply-to: <110212142222.ZM2525@torch.brasslantern.com> Comments: In reply to Bart Schaefer "Re: Another _path_files bug?" (Feb 12, 2:22pm) References: <110210084252.ZM30454@torch.brasslantern.com> <110210092820.ZM30702@torch.brasslantern.com> <20110211203935.4fa6af6a@pws-pc.ntlworld.com> <110212142222.ZM2525@torch.brasslantern.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: Another _path_files bug? MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Feb 12, 2:22pm, Bart Schaefer wrote: } } } Obvious we'll need to find out if the original problem was more general, } } in which case splitting off this case may work but isn't the right fix, } } or if this has repercussions in other simple cases. } } I haven't found any that break, but I don't have, e.g., any files with } multibyte characters in their names handy to try. Hmm, not sure if this is related, but (with "|" representing the cursor position): schaefer<522> ls ../z/T/M| schaefer<522> ls ../zsh-|/T/M I then hit TAB again to get a listing: schaefer<522> ls ../zsh-|/T/M Completing files zsh-3.1.6/ zsh-4.3/ zsh-4.3-build/ zsh-4.3-dynamic/ So far so good. Now hit TAB a third time to cycle through choices: schaefer<522> ls ../zsh-3.1.6/T/M| Completing files zsh-3.1.6/ zsh-4.3/ zsh-4.3-build/ zsh-4.3-dynamic/ Oops, the cursor has moved all the way to the end of the word. I think it should have been positioned right after the 6. Ah, says I to myself, I bet ALWAYS_TO_END is involved here. Let's try again; nope, no diff. Ah, but if I BOTH unsetopt alwaystoend AND start the completion here: schaefer<526> ls ../z|/T/M Then it works: schaefer<526> ls ../zsh-3.1.6|/T/M Completing files zsh-3.1.6/ zsh-4.3/ zsh-4.3-build/ zsh-4.3-dynamic/ This much I can reproduce starting from zsh -f plus compsys. However, with my usual matcher-list style added, the above works but the following breaks: schaefer<528> ls ../|z/T/M schaefer<528> ls ../z.| The style is: zstyle ':completion:*' matcher-list '' 'r:|[-._,]=** r:|=**' \ 'm:{a-zA-Z}={A-Za-z} r:|[-._,]=** r:|=**' 'r:|[-._,]=** r:|=** l:|=*' Any clue why that causes the path tail to get discarded? In the case with no matcher-list, the compadd at line 493 finds nine possible matches for (../)(z/), but with the matcher-list it finds none. The actual files: ../zsh-2.4 ../zsh-3.1.6 ../zsh-4.3-dynamic ../zsh-3.0.5 ../zsh-4.3 ../zsh-forge ../zsh-3.0.8-pre ../zsh-4.3-build ../zsh-tarball (Above are the nine that fail the compadd with the matcher-list. Below are the possible completions of the whole path.) ../zsh-3.1.6/Test/Makefile.in ../zsh-4.3/Test/Makefile.in ../zsh-4.3-build/Test/Makefile ../zsh-4.3/Test/README ../zsh-4.3-dynamic/Test/Makefile