Alignment issue with multiple describes

Alignment issue with multiple describes

[Felipe Contreras]

Hi,

I'm trying to write a completion script for many multiple subcommands,
and I want to group them in different tags, which works more or less
fine, however, 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.

For example, the script below throws this:
---
extraone                    -- extra command one
one  -- command one
two  -- command two
zbiggertoshowthealignissue  -- extra command two
---

If the tags are group together, the problem is less noticeable, but as
soon as you enter the menu, the alignment changes again (to a proper
one).

You can even see this with zsh's official git completion.

Any ideas?

#compdef foobar

_foobar ()
{
	local -a commands extra
	commands=('one:command one' 'two:command two')
	_describe -t commands 'commands' commands
	extra=('extraone:extra command one' 'zbiggertoshowthealignissue:extra
command two')
	_describe -t extra 'extra' extra
}

-- 
Felipe Contreras

Re: Alignment issue with multiple describes

[Felipe Contreras]

Please keep me in Cc.

On Sat, Apr 20, 2013 at 10:03 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:

> I'm trying to write a completion script for many multiple subcommands,
> and I want to group them in different tags, which works more or less
> fine, however, 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.
>
> For example, the script below throws this:
> ---
> extraone                    -- extra command one
> one  -- command one
> two  -- command two
> zbiggertoshowthealignissue  -- extra command two
> ---
>
> If the tags are group together, the problem is less noticeable, but as
> soon as you enter the menu, the alignment changes again (to a proper
> one).
>
> You can even see this with zsh's official git completion.
>
> Any ideas?
>
> #compdef foobar
>
> _foobar ()
> {
>         local -a commands extra
>         commands=('one:command one' 'two:command two')
>         _describe -t commands 'commands' commands
>         extra=('extraone:extra command one' 'zbiggertoshowthealignissue:extra
> command two')
>         _describe -t extra 'extra' extra
> }

-- 
Felipe Contreras

Re: Alignment issue with multiple describes

[Bart Schaefer]

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.

Re: Alignment issue with multiple describes

[Felipe Contreras]

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

Re: Alignment issue with multiple describes

[Bart Schaefer]

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.
 
} 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.

[*] 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.

Re: Alignment issue with multiple describes

[Felipe Contreras]

On Sun, Apr 21, 2013 at 1:27 PM, Bart Schaefer
<schaefer@brasslantern.com> 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

Re: Alignment issue with multiple describes

[Mikael Magnusson]

On 21/04/2013, Felipe Contreras <felipe.contreras@gmail.com> wrote:
>
> 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.

Would appreciate if you stop trolling.

-- 
Mikael Magnusson

Re: Alignment issue with multiple describes

[Felipe Contreras]

On Sun, Apr 21, 2013 at 3:59 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Sun, Apr 21, 2013 at 1:27 PM, Bart Schaefer
> <schaefer@brasslantern.com> wrote:
>> On Apr 21,  3:31am, Felipe Contreras wrote:

>> [*] 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.

I was watching a video about zsh, and the bug is shown right there:
http://www.youtube.com/watch?v=R6hJ8Nqjgv8&t=22m29s

So you have one thousand watchers of this video alone seeing the bug
in full glory. Probably not the best way to show to newcomers that zsh
is polished.

-- 
Felipe Contreras

Re: Alignment issue with multiple describes

[Bart Schaefer]

On Apr 21,  3:59pm, Felipe Contreras wrote:
}
} 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.

Please don't consider anything I say as speaking for "the zsh developers"
as a group.  I'm just answering your questions.

On the other hand, if you actually want to encourage someone to work on
this for you, I think you're going about it the wrong way.
 
} 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.

It is, in fact; but it's not something I'm really in a position to do
anything about.  I already give zsh as much time as I can (in fact more
than I probably ought to), and thankfully most of the people I try to
help out have a better attitude about it than you apparently do.

Enjoy your day.  If any further messages from you manage to spark useful
discussion, you probably should not expect me to Cc you as a courtesy,
because I have no evidence that I'll get any courtesy in return.

Re: Alignment issue with multiple describes

[Felipe Contreras]

On Mon, Apr 22, 2013 at 1:59 AM, Bart Schaefer
<schaefer@brasslantern.com> wrote:
> On Apr 21,  3:59pm, Felipe Contreras wrote:
> }
> } 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.
>
> Please don't consider anything I say as speaking for "the zsh developers"
> as a group.  I'm just answering your questions.
>
> On the other hand, if you actually want to encourage someone to work on
> this for you, I think you're going about it the wrong way.

Why should I care? It's not _my_ project the one with bug. It's not my
project the one that ends up in videos showing obviously wrong
behavior.

If it was, I would fix it, regardless of the attitude of some guy on
some mailing list. My users would thank me for it.

> } 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.
>
> It is, in fact; but it's not something I'm really in a position to do
> anything about.  I already give zsh as much time as I can (in fact more
> than I probably ought to), and thankfully most of the people I try to
> help out have a better attitude about it than you apparently do.

Perhaps, but that doesn't change the facts, and the direction zsh
development is heading to; oblivion.

If you don't care about that happening, by all means, ignore all the warnings.

> Enjoy your day.  If any further messages from you manage to spark useful
> discussion, you probably should not expect me to Cc you as a courtesy,
> because I have no evidence that I'll get any courtesy in return.

Any reasonable person would click 'reply-to-all', which would keep me
in Cc, if your MUA is not braindead. And clicking 'reply-to-all'
consistently is the reasonable thing to do, because properly
configured mailing lists (unlike this one) require this.

Cheers.

-- 
Felipe Contreras