From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5124 invoked by alias); 21 Apr 2013 08:32:05 -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: 31307 Received: (qmail 15058 invoked from network); 21 Apr 2013 08:32:01 -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.6 required=5.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED,RCVD_IN_DNSWL_LOW, T_DKIM_INVALID autolearn=no version=3.3.2 Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.215.44 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=PnQRMOJ7cK2PcTpN2qp1eShQmJYdJ5m2dgnfD/B6c7Y=; b=ovkDtHLIrKUd67RL2AE1IvcbD+xd4mD+RhjUsIiESEbDt04z58kovdOrU16/Gotdi0 i2yFxD83Uzda/7wQ+z6m2+rvdm1K3Fw7AsTvPQ5wGHL9NbdrZuJ24aJqZBbB8YB/71ZT LZ33NsMdKzOx9WqMihlMKZWczI3n3rrfksc5nBPlLx6zxJGwS6aXuI3iLRTX1AeUl5ey WaRVgT2CNOkm7bC/gJkFwXn4JQvHSKODVC9MQq51BnQS7eXeKwmh3cSb5zEu8zLndRHG JAvUmSX1BBIQ/ot5MguVDgCrnWGI1hbtExUZQOOs2dVbmnrCxRbdmhpYGLNQgJa1gSkI QloQ== MIME-Version: 1.0 X-Received: by 10.112.163.6 with SMTP id ye6mr10905886lbb.59.1366533113445; Sun, 21 Apr 2013 01:31:53 -0700 (PDT) In-Reply-To: <130420232740.ZM12405@torch.brasslantern.com> References: <130420232740.ZM12405@torch.brasslantern.com> Date: Sun, 21 Apr 2013 03:31:53 -0500 Message-ID: Subject: Re: Alignment issue with multiple describes From: Felipe Contreras To: Bart Schaefer Cc: zsh-workers@zsh.org, Felipe Contreras Content-Type: text/plain; charset=UTF-8 On Sun, Apr 21, 2013 at 1:27 AM, Bart Schaefer wrote: > 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. Well, I didn't choose it, that's the way it is by default. > 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. That is indeed very interesting, but to me, it's a bug that the output of the first completion is not the same as the second. And that it also depends on the order of the _describe commands. The completion clearly waits until all the _describe commands have been issued, and then renders them (ordered), so couldn't this maximum width be calculated at that point? The second bug about the leaking of the length I don't think is that important. The user probably won't even notice. Cheers. -- Felipe Contreras