From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23311 invoked by alias); 13 Sep 2011 17:40:37 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 16346 Received: (qmail 17852 invoked from network); 13 Sep 2011 17:40:35 -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: <110913104008.ZM14525@torch.brasslantern.com> Date: Tue, 13 Sep 2011 10:40:08 -0700 In-reply-to: Comments: In reply to Yuri DElia "Re: Completion lists" (Sep 13, 4:07pm) References: <110913074320.ZM14249@torch.brasslantern.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-users@zsh.org Subject: Re: Completion lists MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Sep 13, 4:07pm, Yuri DElia wrote: } } $ touch fileaa } $ touch filebb } $ ls file } } (this will correctly highlight "a" and "b") } } suddenly: } } $ ls ./ } } will still match the second expression '=(#b)(?)*==1' but here (?) } will capture the first 4 characters, not just the first one. The behvior I see is that it *skips* the first 4 characters and highlights the fifth one, i.e., it continues to highlight "a" and "b" in those two files but highlights nothing in file names with fewer than 5 characters. Still wrong, but not in the way you said. } The length is dependent on previous PREFIX ("file" here). } } Bug? It would appear so. compstate[insert_positions]=5 at the end of the "ls ./" although compstate[unambiguous_positions]=2. So the pattern is matched correctly, but incorrectly is compared to the string beginning at the 5th position. Some part of the internal state that should be getting cleared when the completion restarts, is not. This perists across ZLE restarts but not across different words in command position, e.g. if you complete for "ls" twice in a row it's broken, but if you complete for "ls" and then for "setopt" and then back to "ls" again it works correctly all three times (or at least did for me in a couple of quick trials). Unfortunately I'm not going to have an opportunity to run that down anytime soon. Peter?