From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23164 invoked by alias); 21 Apr 2013 20:59: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: 31320 Received: (qmail 16316 invoked from network); 21 Apr 2013 20:59: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.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.45 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=hNoxYkK5fl9tANzkwHNO62nxeGFxyB6i6EZjXCNICGE=; b=Dy7ipQBcuX9F1s3b2IRvJLFKb+6JF5Te+oo0ejyXHnI9aprY+WNuGAVLr/AN/mkMBU t/OKmssjqx3bOdo/S8hTW2q6Job6qcQGM1FT76eUHDnmgBfM/mJeIzdflvnKTWYQZkTj PFwP3yi+uZ90SH03cqPyb61C/N64TPcEXW3kC5IIyy41JMsyVyJA/QFIyQcYP9qx4muZ 7K5hUlRW6aAUxcrojuPNlYPbmlsy6Czg+m8I4GyEcKM8Es1KsleQA21kXKSy/pzf2AkC wxikK4tS26WacfZ3Ouf9Rwnr0IjeT+w62peF0bXOKVqYUuikTKYLa4dPkeTED9fNf46R LONg== MIME-Version: 1.0 X-Received: by 10.112.146.133 with SMTP id tc5mr11856579lbb.88.1366577983698; Sun, 21 Apr 2013 13:59:43 -0700 (PDT) In-Reply-To: <130421112734.ZM6597@torch.brasslantern.com> References: <130420232740.ZM12405@torch.brasslantern.com> <130421112734.ZM6597@torch.brasslantern.com> Date: Sun, 21 Apr 2013 15:59:43 -0500 Message-ID: Subject: Re: Alignment issue with multiple describes From: Felipe Contreras To: Bart Schaefer Cc: zsh-workers@zsh.org, Felipe Contreras Garza Content-Type: text/plain; charset=UTF-8 On Sun, Apr 21, 2013 at 1:27 PM, Bart Schaefer wrote: > On Apr 21, 3:31am, Felipe Contreras wrote: > } > } > 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. > > Yes, so that a simple zstyle setting can be used to alter display order, > rather than having to rewrite the shell functions. I cannot change the zstyle setting of everyone in the world. Also, there's no zstyle setting that does the right thing, actually. If you have one, please, let me know which is it. From what I can see, they all throw buggy output. > } 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? > > No. The display layout is calculated as each group is created and is > stored with the data structures. The render-time code is relatively > dumb (except for all the smarts about manipulating the terminal device > for coloring and so on) and just spits out what the data structures say. > As far as I can tell (and I'm by no means the person most familar with > this code [*]) the layout of each group is calculated without reference > to the other groups except for static globals that keep track of the > widest column from any group encountered so far. It should still be possible to traverse the groups, calculate the widest column, store it globally, and _then_ do the layout calculation. Even better would be to not do the column width at the layout calculation level, but simply divide by columns, and let the render-time code or some higher level function with knowledge of multiple groups determine the width. It doesn't matter how it's done, as long as the bug is fixed. > [*] Unfortunately the person most familiar with this code has not been > active in zsh development for 12 years. On the other hand, it's been > 12 years and you're the first person ever to notice/mention this, so it > probably doesn't affect anyone's usage of the shell. It probably does, but nobody cares enough about subtle bugs in zsh. Specially since most completions don't use more than one _description, the git completion being one exception. Anyway, I'm going to label this as a bug the zsh developers are unwilling to fix, and I'm going to work around it by avoiding more than one _description with actual descriptions. And BTW, the fact that you have part of the code nobody understands, has touched, or is willing to touch in a decade should be a concern to you. And so should be the decreasing year-over-year contributions and commits: https://www.ohloh.net/p/zsh/commits/summary I would say this is a sign that you should reconsider your development practices. But whatever, keep going the way you are going if you want. Cheers. -- Felipe Contreras