From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23072 invoked by alias); 21 Apr 2013 06:27:52 -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: 31306 Received: (qmail 17068 invoked from network); 21 Apr 2013 06:27:51 -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 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <130420232740.ZM12405@torch.brasslantern.com> Date: Sat, 20 Apr 2013 23:27:40 -0700 In-reply-to: Comments: In reply to Felipe Contreras "Alignment issue with multiple describes" (Apr 20, 10:03pm) References: X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Felipe Contreras , zsh-workers@zsh.org Subject: Re: Alignment issue with multiple describes MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Apr 20, 10:03pm, Felipe Contreras wrote: } } I've noticed a problem when using more than one } describe: the completion's description is aligned, but only to the } same description, even if they are not grouped. In part the issue here is that they *are* grouped, implicitly, as you can see here: schaefer<504> foobar Completing commands one -- command one two -- command two Completing extra extraone -- extra command one zbiggertoshowthealignissue -- extra command two That you've chosen not to display the groups separately doesn't mean they aren't grouped internally. Curiously, though, the above happens for me only the very first time that the completion is tried. Here's my second try: schaefer<504> foobar Completing commands one -- command one two -- command two Completing extra extraone -- extra command one zbiggertoshowthealignissue -- extra command two There's no difference in shell code executed (_complete_debug output), so the whole problem seems to hinge on whether compadd has been invoked at least once before. As a third example, if I complete after "ls --" to force a long list of options, and then complete after foobar, I get this: schaefer<504> foobar Completing commands one -- command one two -- command two Completing extra extraone -- extra command one zbiggertoshowthealignissue -- extra command two Note that the alignment is "correct" but with a lot more whitespace than the previous "correct" display. This is ringing a very distant bell. I think that in order to get the alignment right, you have to be sure to compadd [and thus _describe] the longest strings first; compadd has no way of knowing how many groups there will be, and can't go back and fix up a previous group when aligning a new one, but it does remember the greatest length it has seen in all groups so far, and aligns everything against that. Leaking that length across separate ZLE passes, as appears to be the case with completing for "ls" first, is probably a bug -- something should be getting reset on zle entry or exit, but is not.