* Alignment issue with multiple describes @ 2013-04-21 3:03 Felipe Contreras 2013-04-21 3:03 ` Felipe Contreras 2013-04-21 6:27 ` Bart Schaefer 0 siblings, 2 replies; 10+ messages in thread From: Felipe Contreras @ 2013-04-21 3:03 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Alignment issue with multiple describes 2013-04-21 3:03 Alignment issue with multiple describes Felipe Contreras @ 2013-04-21 3:03 ` Felipe Contreras 2013-04-21 6:27 ` Bart Schaefer 1 sibling, 0 replies; 10+ messages in thread From: Felipe Contreras @ 2013-04-21 3:03 UTC (permalink / raw) To: zsh-workers; +Cc: 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Alignment issue with multiple describes 2013-04-21 3:03 Alignment issue with multiple describes Felipe Contreras 2013-04-21 3:03 ` Felipe Contreras @ 2013-04-21 6:27 ` Bart Schaefer 2013-04-21 8:31 ` Felipe Contreras 1 sibling, 1 reply; 10+ messages in thread From: Bart Schaefer @ 2013-04-21 6:27 UTC (permalink / raw) To: Felipe Contreras, zsh-workers 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Alignment issue with multiple describes 2013-04-21 6:27 ` Bart Schaefer @ 2013-04-21 8:31 ` Felipe Contreras 2013-04-21 18:27 ` Bart Schaefer 0 siblings, 1 reply; 10+ messages in thread From: Felipe Contreras @ 2013-04-21 8:31 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-workers, 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Alignment issue with multiple describes 2013-04-21 8:31 ` Felipe Contreras @ 2013-04-21 18:27 ` Bart Schaefer 2013-04-21 20:59 ` Felipe Contreras 0 siblings, 1 reply; 10+ messages in thread From: Bart Schaefer @ 2013-04-21 18:27 UTC (permalink / raw) To: Felipe Contreras; +Cc: zsh-workers 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Alignment issue with multiple describes 2013-04-21 18:27 ` Bart Schaefer @ 2013-04-21 20:59 ` Felipe Contreras 2013-04-21 21:09 ` Mikael Magnusson ` (2 more replies) 0 siblings, 3 replies; 10+ messages in thread From: Felipe Contreras @ 2013-04-21 20:59 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-workers, Felipe Contreras Garza 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Alignment issue with multiple describes 2013-04-21 20:59 ` Felipe Contreras @ 2013-04-21 21:09 ` Mikael Magnusson 2013-04-21 22:00 ` Felipe Contreras 2013-04-22 6:59 ` Bart Schaefer 2 siblings, 0 replies; 10+ messages in thread From: Mikael Magnusson @ 2013-04-21 21:09 UTC (permalink / raw) To: Felipe Contreras; +Cc: zsh-workers 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Alignment issue with multiple describes 2013-04-21 20:59 ` Felipe Contreras 2013-04-21 21:09 ` Mikael Magnusson @ 2013-04-21 22:00 ` Felipe Contreras 2013-04-22 6:59 ` Bart Schaefer 2 siblings, 0 replies; 10+ messages in thread From: Felipe Contreras @ 2013-04-21 22:00 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-workers, Felipe Contreras Garza 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Alignment issue with multiple describes 2013-04-21 20:59 ` Felipe Contreras 2013-04-21 21:09 ` Mikael Magnusson 2013-04-21 22:00 ` Felipe Contreras @ 2013-04-22 6:59 ` Bart Schaefer 2013-04-22 7:30 ` Felipe Contreras 2 siblings, 1 reply; 10+ messages in thread From: Bart Schaefer @ 2013-04-22 6:59 UTC (permalink / raw) To: Felipe Contreras; +Cc: zsh-workers 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Alignment issue with multiple describes 2013-04-22 6:59 ` Bart Schaefer @ 2013-04-22 7:30 ` Felipe Contreras 0 siblings, 0 replies; 10+ messages in thread From: Felipe Contreras @ 2013-04-22 7:30 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-workers, Felipe Contreras Garza 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2013-04-22 7:30 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-04-21 3:03 Alignment issue with multiple describes Felipe Contreras 2013-04-21 3:03 ` Felipe Contreras 2013-04-21 6:27 ` Bart Schaefer 2013-04-21 8:31 ` Felipe Contreras 2013-04-21 18:27 ` Bart Schaefer 2013-04-21 20:59 ` Felipe Contreras 2013-04-21 21:09 ` Mikael Magnusson 2013-04-21 22:00 ` Felipe Contreras 2013-04-22 6:59 ` Bart Schaefer 2013-04-22 7:30 ` Felipe Contreras
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).