* issues when coloring only descriptions in menu list @ 2017-04-17 17:02 apfelsinenhain 2017-04-17 18:05 ` Daniel Shahaf 2017-04-17 18:52 ` Bart Schaefer 0 siblings, 2 replies; 7+ messages in thread From: apfelsinenhain @ 2017-04-17 17:02 UTC (permalink / raw) To: zsh-users [-- Attachment #1: Type: text/plain, Size: 894 bytes --] Hello. I wanted to have a different colour for the per-match descriptions in the menu list, but I can't get it to work in all cases. - start a clean shell with `zsh -f` - execute: > zmodload zsh/complist > autoload -U compinit && compinit > > zstyle ':completion:*' list-separator "XX" > zstyle ':completion:*:default' list-colors '=XX*=31' > > _a () { > _arguments \ > '(--first -f)'{--first,-f}'[first should be red]' \ > '--second[second should be red]' > } > compdef _a a - try: - `a -<tab>` WILL show color - `a --<tab>` will NOT show color This doesn't just happen when using `_arguments`. Using `_describe` and those specific zstyle's also doesn't work. Screenshots + more tests & examples can be found here: https://gist.github.com/Orangenhain/c9ac6ea47f187589813b9887c300a897 Is that a bug? Am I using list-colors wrong? Thanks. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: issues when coloring only descriptions in menu list 2017-04-17 17:02 issues when coloring only descriptions in menu list apfelsinenhain @ 2017-04-17 18:05 ` Daniel Shahaf 2017-04-17 20:40 ` apfelsinenhain 2017-04-17 21:12 ` apfelsinenhain 2017-04-17 18:52 ` Bart Schaefer 1 sibling, 2 replies; 7+ messages in thread From: Daniel Shahaf @ 2017-04-17 18:05 UTC (permalink / raw) To: apfelsinenhain; +Cc: zsh-users apfelsinenhain@gmx.de wrote on Mon, Apr 17, 2017 at 19:02:15 +0200: > > zstyle ':completion:*' list-separator "XX" > > zstyle ':completion:*:default' list-colors '=XX*=31' > > - try: > - `a -<tab>` WILL show color > - `a --<tab>` will NOT show color Not sure whether it's a bug, but this setting seems to work: zstyle ':completion:*:default' list-colors '=(#b)*(XX*)==31' ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: issues when coloring only descriptions in menu list 2017-04-17 18:05 ` Daniel Shahaf @ 2017-04-17 20:40 ` apfelsinenhain 2017-04-17 21:12 ` apfelsinenhain 1 sibling, 0 replies; 7+ messages in thread From: apfelsinenhain @ 2017-04-17 20:40 UTC (permalink / raw) To: Daniel Shahaf; +Cc: zsh-users [-- Attachment #1: Type: text/plain, Size: 937 bytes --] Interesting ... this seemed to work at first for me, but further testing seems to turn up an issue as well. If I try to specify a colour for the non-match part of the pattern, then for `a -><tab>` I *do* see the description in red, but the non-match part isn't coloured ... for the other test cases (`a --` & b & c) it does show both colors correctly. Screenshot: https://cloud.githubusercontent.com/assets/168694/25103774/0a3122f0-23be-11e7-9ded-ef60067621a7.png On 17 Apr 2017, at 20:05, Daniel Shahaf wrote: > apfelsinenhain@gmx.de wrote on Mon, Apr 17, 2017 at 19:02:15 +0200: >>> zstyle ':completion:*' list-separator "XX" >>> zstyle ':completion:*:default' list-colors '=XX*=31' >> >> - try: >> - `a -<tab>` WILL show color >> - `a --<tab>` will NOT show color > > Not sure whether it's a bug, but this setting seems to work: > > zstyle ':completion:*:default' list-colors '=(#b)*(XX*)==31' ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: issues when coloring only descriptions in menu list 2017-04-17 18:05 ` Daniel Shahaf 2017-04-17 20:40 ` apfelsinenhain @ 2017-04-17 21:12 ` apfelsinenhain 1 sibling, 0 replies; 7+ messages in thread From: apfelsinenhain @ 2017-04-17 21:12 UTC (permalink / raw) To: zsh-users [-- Attachment #1: Type: text/plain, Size: 566 bytes --] In response to Bart Schaefer's message http://www.zsh.org/mla/users/2017/msg00331.html I've tried what you described, and also added a colour for the non-match part ... that gets even more fun, because the colour shows up for the option that contains the match, but not others: https://cloud.githubusercontent.com/assets/168694/25104671/85b5e3fe-23c1-11e7-9b3d-2b65352ff06c.png --- Sorry, his response came in before I had confirmed my mail address for this mailing list. I didn't get his response via mail, and thus can't properly reply to it. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: issues when coloring only descriptions in menu list 2017-04-17 17:02 issues when coloring only descriptions in menu list apfelsinenhain 2017-04-17 18:05 ` Daniel Shahaf @ 2017-04-17 18:52 ` Bart Schaefer 2017-04-17 20:12 ` Bart Schaefer 1 sibling, 1 reply; 7+ messages in thread From: Bart Schaefer @ 2017-04-17 18:52 UTC (permalink / raw) To: zsh-users On Apr 17, 7:02pm, apfelsinenhain@gmx.de wrote: } } I wanted to have a different colour for the per-match descriptions in } the menu list, but I can't get it to work in all cases. } } > zstyle ':completion:*' list-separator "XX" } > zstyle ':completion:*:default' list-colors '=XX*=31' [...] } - `a -<tab>` WILL show color } - `a --<tab>` will NOT show color I'm puzzled why the FIRST of those cases works, because I would expect you to need this: zstyle ':completion:*:default' list-colors '=(#b)*(XX*)=0=31' which does work for both cases. Something about having both --first and -f as matches is causing the "display string" against which the pattern is compared to start only after the two columns of matches, whereas when there is only a single column of matches each full line becomes one "display string". ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: issues when coloring only descriptions in menu list 2017-04-17 18:52 ` Bart Schaefer @ 2017-04-17 20:12 ` Bart Schaefer 2017-04-17 22:58 ` Bart Schaefer 0 siblings, 1 reply; 7+ messages in thread From: Bart Schaefer @ 2017-04-17 20:12 UTC (permalink / raw) To: zsh-users On Apr 17, 11:52am, Bart Schaefer wrote: } } I'm puzzled why the FIRST of those cases works, because I would expect } you to need this: } } zstyle ':completion:*:default' list-colors '=(#b)*(XX*)=0=31' This demonstrates what is going on: autoload compinit && compinit -D -u zstyle ':completion:*' list-separator "XX" zstyle ':completion:*:default' list-colors '=(#b)*(XX*)(?)==31=33;40' _a () { _arguments \ {--first,-f}'[first should be red]' \ '--barXXfoo[watch what happens here]' \ '--second[second should be red]' } compdef _a a Now try TAB after each of "a -" and "a --" and watch where the black background appears. I think this has something to do with padding the columns when there is more than one match to put on the same line. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: issues when coloring only descriptions in menu list 2017-04-17 20:12 ` Bart Schaefer @ 2017-04-17 22:58 ` Bart Schaefer 0 siblings, 0 replies; 7+ messages in thread From: Bart Schaefer @ 2017-04-17 22:58 UTC (permalink / raw) To: zsh-users On Apr 17, 1:12pm, Bart Schaefer wrote: } } This demonstrates what is going on: Apparently I should have explained a bit more thoroughly. The tl;dr of this is that the list-colors patterns have to be able to properly color completions (alone), descriptions (alone but with lots of trailing whitespace), or single lines consisting of a completion followed by a description. This can be done either by using more than one pattern or by clever use of backreferences. Read on for too much detail. } _a () { } _arguments \ } {--first,-f}'[first should be red]' \ } '--barXXfoo[watch what happens here]' \ } '--second[second should be red]' } } The list-colors style is documented as using a pattern that is matched against the "display strings" in the completion listing. However, what exactly constitutes a "display string" is not well-described. Given the above call to _arguments, when TAB is pressed after a single hyphen ("a -") the following display elements (I'm carefully not yet naming them "display strings") are generated: --first (potential completion) first should be red (description of --first) -f (potential completion) first should be red (description of -f) --barXXfoo (etc.) watch what happens here --second second should be red The descriptions are then examined to see if there are any completions that share the same description. If there are, those elements are to be grouped together. So we end up with --first (potential completion, group 1) -f (potential completion, group 1) first should be red (description of group 1) --barXXfoo (group 2) watch what happens here (description of group 2) --second (etc.) second should be red These are next examined to determine how to put them in columns. The result is that we need three columns, two for completions (--first and -f appearing together) and one for descriptions. Some lines will not have all three columns, so the first column in those lines must be padded to the width of the two columns in the other line to keep the third column visually stacked. Next it's determined how to lay these out on the screen, with the requirement that the third column must have the list-seprator added at the beginning. Because of the alignment requirement for the third column, the preceding columns in each of the other lines must be handled separately. Here's where we get into "display strings": In order to solve the alignment problem, the display is broken into seven "display strings" corresponding to the seven elements in my second list above, and then those are arranged in their sorted order and with appropriate padding so that the the correct number of lines with the correct alignment of columns is produced when the seven elements are printed, in that order, left-to-right (wrap) left-to-right (etc.) The third column (description) is padded on the right with spaces in order to force wrapping to occur at the correct position. This can be see when colors are added (next step) by setting the background color of the last character. Finally the list-colors pattern is matched against each of those seven strings. *(XX*)(?) matches "--barXXfoo" and "XX watch what happens here" but does not match "--first" and does not match "-f". Then it matches "XX first should be red", and so on. So you get no color on the things not matched, and colors on those that are matched. If instead TAB is pressed after "a --", we get --first first should be red --barXXfoo watch what happens here --second second should be red There's no duplication here, so there's no need to break this up into multiple columns. Everything needed can be done in one line per potential completion, just by inserting proper padding before the list-separator. So this is minimized to use only one "display string" per line, "--barXXfoo XX watch ...", "--first XX first ..." etc. The pattern *(XX*)(?) is then matched against those three strings and matches all of them, with the leading * greedily consuming the first "XX" in the "--barXXfoo" line so it's not part of the (XX*) reference and therefore is not colored. The latter is what I thought would be happening in both cases, when I made my first reply. There's an additional complication mentioned in a previous thread (I forget whether on -workers or -users) that the complist module assumes the default list-colors foreground+background will always be the same as the default terminal foreground+background and so does not assert color changes in all necessary cases when list-colors has been told to use something else for one of those defaults. Fortunately you're not also tickling that one or things would be even harder to explain. -- Barton E. Schaefer ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2017-04-17 22:58 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-04-17 17:02 issues when coloring only descriptions in menu list apfelsinenhain 2017-04-17 18:05 ` Daniel Shahaf 2017-04-17 20:40 ` apfelsinenhain 2017-04-17 21:12 ` apfelsinenhain 2017-04-17 18:52 ` Bart Schaefer 2017-04-17 20:12 ` Bart Schaefer 2017-04-17 22:58 ` Bart Schaefer
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).