Re: Alignment issue with multiple describes

[Bart Schaefer <schaefer@brasslantern.com>]

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.