Re: Alignment issue with multiple describes

[Felipe Contreras <felipe.contreras@xxxxxxxxx>]

On Sun, Apr 21, 2013 at 1:27 AM, Bart Schaefer
<schaefer@xxxxxxxxxxxxxxxx> 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