From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21861 invoked by alias); 17 Apr 2017 22:58:20 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 22679 Received: (qmail 23312 invoked from network); 17 Apr 2017 22:58:20 -0000 X-Qmail-Scanner-Diagnostics: from mail-ua0-f173.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(209.85.217.173):SA:0(0.5/5.0):. Processed in 1.22333 secs); 17 Apr 2017 22:58:20 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RCVD_IN_SORBS_SPAM,SPF_PASS, T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.1 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.217.173 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version; bh=7ku+VysmAKijs87tSGVcCbI5+lD4mgXYREJq6L3OvvU=; b=ADC0XDV6G6/xPYrucPoMf150dX0zRrY000U48OkiFddSogYktsNmUw1Yk4+IGw+ddZ uhJ2suSyKt0lryDKHvIuYbM9Q1OZSw9B6oCv7iuvC0K5xiXsWvqUm6X0hWDoTZHsBMye maFhQMgAXqHQcs4M8F0qOv/LOih/NM545pnNw+o0vV/9ZFj4eE77JJ6BQ520Vwy7E+M8 QEMoJafDZ8RWzzvCSkgHIbV+ic7HPOn7Sx4x2ZIyOmScWv0SvuLFtnZwoeBgmDSaeEeu AHY62I6z8UaY1ydWkwIz5iLPsq1ZEXtoIAESIRXFfm41ZFbp136d5iahB8BCHfciF+Jm YbJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version; bh=7ku+VysmAKijs87tSGVcCbI5+lD4mgXYREJq6L3OvvU=; b=ch8GGo8ao57M40KzpM/FW1jEVPVrq8KC0rLkLZYUqaOgFCPX8aq/8PsxkhWnf7Kuim lzzXFQNxatmMuY0XlggKbfWVLENAM/Y7OKyO2+Jav7iOtT1tNVKwpoMJ+m9qpuTR7ln9 A1A6pTa1mve8Qy4S9j22lAyEQ+klPsUbTRB5u6CP7ZEpaiTf1G8SLpot+Zts/2UzlNIk mtETde09P6DPhqq6bZnkEdNf8MYOzOIzFgWVnCr9PBZtQVUHwdr72ZZLIfK716EJUq2C V6aakHWcY2ijqifSD1ilvjZ0ytzzXv95sVv3uTNoteREog7XxDTnSR5llTIoL01jfwBC CyGg== X-Gm-Message-State: AN3rC/7R6zpW1vyX5nsl8fDHVIL/io3+YmidmhINiDkFc5Aj0M/ChyAx qo9MaacbN2Qkg3MB X-Received: by 10.176.3.109 with SMTP id 100mr11440936uat.87.1492469892624; Mon, 17 Apr 2017 15:58:12 -0700 (PDT) From: Bart Schaefer Message-Id: <170417155843.ZM25343@torch.brasslantern.com> Date: Mon, 17 Apr 2017 15:58:43 -0700 In-Reply-To: <170417131202.ZM24940@torch.brasslantern.com> Comments: In reply to Bart Schaefer "Re: issues when coloring only descriptions in menu list" (Apr 17, 1:12pm) References: <28ECE9C6-6C9F-4707-9295-790E89C16C1B@gmx.de> <170417115258.ZM24732@torch.brasslantern.com> <170417131202.ZM24940@torch.brasslantern.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-users@zsh.org Subject: Re: issues when coloring only descriptions in menu list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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