From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12716 invoked by alias); 4 Oct 2013 04:01:56 -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: 31785 Received: (qmail 3324 invoked from network); 4 Oct 2013 04:01:50 -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 autolearn=ham version=3.3.2 From: Bart Schaefer Message-id: <131003210151.ZM3277@torch.brasslantern.com> Date: Thu, 03 Oct 2013 21:01:51 -0700 In-reply-to: <20131003172007.57e1e825@pwslap01u.europe.root.pri> Comments: In reply to Peter Stephenson "Re: Bug somewhere in verbose output for completion listing" (Oct 3, 5:20pm) References: <20131003140025.227f5bc1@pwslap01u.europe.root.pri> <131003075018.ZM991@torch.brasslantern.com> <131003080956.ZM1033@torch.brasslantern.com> <20131003172007.57e1e825@pwslap01u.europe.root.pri> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: "Zsh Hackers' List" Subject: Re: Bug somewhere in verbose output for completion listing MIME-version: 1.0 Content-type: text/plain; charset=us-ascii A final thought. On Oct 3, 5:20pm, Peter Stephenson wrote: } } so premaxw has gone up. Sure enough it doesn't get reset with most of the } other stuff in cd_init(), and I can't see any reason why it shouldn't } be. It must start off initially at 0 so resetting it to 0 each time } we initialise the state can't make anything worse (theoretically). We're now back to the state that Felipe Contreras complained about in the earlier thread that I referenced: torch% _foobar () { local -a commands extra commands=('one:command one' 'two:command two') _describe -t commands 'commands' commands extra=('extraone:extra command one' 'zbiggertoshowthealignissue:extra command two') _describe -t extra 'extra' extra } torch% compdef _foobar foobar torch% foobar extraone -- extra command one one -- command one two -- command two zbiggertoshowthealignissue -- extra command two torch% This happens because there are two calls to _describe for the different groups, and each call to _describe calls compdescribe -I which then resets the maximum width. (Previously it would look strange like this the first time you tried it, and then [because premaxw was NOT reset] they would all line up on the widest stance on subsequent attempts. Now at least it's consistently "mis-aligned" every time.) The behavior looks a little better if you sort the matches by group: torch% zstyle :completion:\* group-name '' torch% foobar one -- command one two -- command two extraone -- extra command one zbiggertoshowthealignissue -- extra command two To add a bit to the discussion from the previous thread, this is as it is because the entire "one -- command one" (et al.) is assembled as a single string by compdescribe. The data structure does not store pairs of (match,description) that can be realigned upon display.