From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19225 invoked by alias); 23 Oct 2016 17:36:28 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 39715 Received: (qmail 16081 invoked from network); 23 Oct 2016 17:36:28 -0000 X-Qmail-Scanner-Diagnostics: from know-smtprelay-omc-6.server.virginmedia.net 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(80.0.253.70):SA:0(-0.0/5.0):. Processed in 0.49139 secs); 23 Oct 2016 17:36:28 -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.0 required=5.0 tests=SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: p.w.stephenson@ntlworld.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _smtprelay.virginmedia.com designates 80.0.253.70 as permitted sender) X-Originating-IP: [86.21.219.59] X-Spam: 0 X-Authority: v=2.1 cv=cLcdyQqN c=1 sm=1 tr=0 a=utowdAHh8RITBM/6U1BPxA==:117 a=utowdAHh8RITBM/6U1BPxA==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=q2GGsy2AAAAA:8 a=fucjL6KTE6-oLF6RS64A:9 a=CjuIK1q_8ugA:10 a=z9dJwno5l634igLiVhy-:22 Date: Sun, 23 Oct 2016 18:30:48 +0100 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: zsh/complist colours improperly handle multibyte characters Message-ID: <20161023183048.3b6d21bb@ntlworld.com> In-Reply-To: <161020210735.ZM6446@torch.brasslantern.com> References: <161020210735.ZM6446@torch.brasslantern.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 20 Oct 2016 21:07:35 -0700 Bart Schaefer wrote: > The problem with the (#b) example is not that the pattern has matched > improperly, but that #ifdef MULTIBYTE_SUPPORT has never been worked > into complist.c:clprintfmt(). So it is counting the bytes rather than > the display width when deciding where to start/stop coloring. So something like this might be better? This is counting characters properly, but not taking into account the width of the character may be greater than 1. As the outer loop is assuming one position per character I don't know how to fix that properly. Probably incrementing cc by the width and doing something clever with the "beg =" is a further imporvement, but I have no idea what to about i. pws diff --git a/Src/Zle/complist.c b/Src/Zle/complist.c index 8aeb6c3..39ac782 100644 --- a/Src/Zle/complist.c +++ b/Src/Zle/complist.c @@ -662,7 +662,9 @@ clprintfmt(char *p, int ml) initiscol(); - for (; *p; p++) { + while (*p) { + convchar_t chr; + int chrlen = MB_METACHARLENCONV(p, &chr); doiscol(i++); cc++; if (*p == '\n') { @@ -673,11 +675,16 @@ clprintfmt(char *p, int ml) if (ml == mlend - 1 && (cc % zterm_columns) == zterm_columns - 1) return 0; - if (*p == Meta) { + while (chrlen) { + if (*p == Meta) { + p++; + chrlen--; + putc(*p ^ 32, shout); + } else + putc(*p, shout); + chrlen--; p++; - putc(*p ^ 32, shout); - } else - putc(*p, shout); + } if ((beg = !(cc % zterm_columns))) ml++; if (mscroll && !(cc % zterm_columns) &&