From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16165 invoked from network); 14 Apr 2008 09:04:07 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.4 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 14 Apr 2008 09:04:07 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 59678 invoked from network); 14 Apr 2008 09:03:58 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 14 Apr 2008 09:03:58 -0000 Received: (qmail 5561 invoked by alias); 14 Apr 2008 09:03:55 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 24810 Received: (qmail 5547 invoked from network); 14 Apr 2008 09:03:55 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 14 Apr 2008 09:03:55 -0000 Received: from cluster-g.mailcontrol.com (cluster-g.mailcontrol.com [85.115.41.190]) by bifrost.dotsrc.org (Postfix) with ESMTP id 720CB8043AC7 for ; Mon, 14 Apr 2008 11:03:47 +0200 (CEST) Received: from cameurexb01.EUROPE.ROOT.PRI ([62.189.241.200]) by rly06g.srv.mailcontrol.com (MailControl) with ESMTP id m3E8xwQi011515 for ; Mon, 14 Apr 2008 10:03:21 +0100 Received: from news01.csr.com ([10.103.143.38]) by cameurexb01.EUROPE.ROOT.PRI with Microsoft SMTPSVC(6.0.3790.3959); Mon, 14 Apr 2008 10:02:32 +0100 Received: from news01.csr.com (localhost.localdomain [127.0.0.1]) by news01.csr.com (8.14.2/8.13.4) with ESMTP id m3E92WXM032171 for ; Mon, 14 Apr 2008 10:02:32 +0100 Received: from csr.com (pws@localhost) by news01.csr.com (8.14.2/8.14.2/Submit) with ESMTP id m3E92WsR032168 for ; Mon, 14 Apr 2008 10:02:32 +0100 Message-Id: <200804140902.m3E92WsR032168@news01.csr.com> X-Authentication-Warning: news01.csr.com: pws owned process doing -bs To: "Zsh Hackers' List" Subject: Re: PATCH: (large) initial support for combining characters in ZLE. In-reply-to: <080413103257.ZM700@torch.brasslantern.com> References: <20080413175442.0e95a241@pws-pc> <080413103257.ZM700@torch.brasslantern.com> Comments: In-reply-to Bart Schaefer message dated "Sun, 13 Apr 2008 10:32:57 -0700." Date: Mon, 14 Apr 2008 10:02:32 +0100 From: Peter Stephenson X-OriginalArrivalTime: 14 Apr 2008 09:02:32.0443 (UTC) FILETIME=[46315CB0:01C89E0E] X-Scanned-By: MailControl A-08-00-05 (www.mailcontrol.com) on 10.71.0.116 X-Virus-Scanned: ClamAV 0.91.2/6755/Mon Apr 14 09:35:52 2008 on bifrost X-Virus-Status: Clean Bart Schaefer wrote: > On Apr 13, 5:54pm, Peter Stephenson wrote: > } To get combining characters to do anything useful, you will need to > } set the option COMBINING_CHARS. There's no "ZLE" there because it > } already has a minimal effect on the main shell in the [[:WORD:]] > } test: arguably zero-width punctuation characters should be considered > } part of the word regardless of the option, i.e. even if displayed > } specially, and I might change this. > > Pardon if I'm just not thinking this through far enough, but what if > any affect does this have on completion of strings that contain zero- > width characters? > > Mainly I'm wondering whether NO_combiningchars needs to be added to > _comp_options, or something of that ilk. It shouldn't have a major effect. The completion system inserts multibyte strings that get converted to wide characters later on; when this is redisplayed it goes into the same logic in zrefresh() that is already basically working. The only issue I can see is if the cursor ends up on a combining character at that point; for example, when completing characters that only differ by the subsequent combining characters. Actually, I can't think of a case where that can happen. Either we insert the unique part to the left of the cursor, or we insert one of the choices completely. As long as we don't put anything under the cursor, things will work. There's the slightly odd effect that characters differing by combining characters will appear treated as if the base character matches: that's a bug, but no worse than the current situation. Hence the only effects I'm expecting are minor edge effects which can probably be fixed up with a suitably placed alignmultiwordright(). I wonder, in fact, if it might be worth putting that in unmetafy_line(), as below... In any case I'd like to keep the option turned on and see what happens, since I'm not expecting anything catastrophic and I need to know if there is. > } - As always, completion is so complicated it could do pretty much > } anything > > Well, yeah. So perhaps I should refine my question: What effect is > this eventually intended to have on completion when all of the details > have been worked out? (Something which may, conceivably, never come > entirely to pass, I admit). I don't think it should have any, for the reasons given above. Anything that looks different, other than having the characters displayed more correctly, is probably a bug. For example, I've made no attempt to do anything clever when displaying completion lists. They need to be fixed up along the same lines as the command line. Index: Src/Zle/zle_tricky.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/Zle/zle_tricky.c,v retrieving revision 1.91 diff -u -r1.91 zle_tricky.c --- Src/Zle/zle_tricky.c 13 Apr 2008 16:58:43 -0000 1.91 +++ Src/Zle/zle_tricky.c 14 Apr 2008 08:59:11 -0000 @@ -978,6 +978,14 @@ zlemetaline[zlemetall] = '\0'; zleline = stringaszleline(zlemetaline, zlemetacs, &zlell, &linesz, &zlecs); +#ifdef MULTIBYTE_SUPPORT + /* + * If we inserted combining characters under the cursor we + * won't have tested the effect yet. So fix it up now. + */ + alignmultiwordright(1); +#endif + free(zlemetaline); zlemetaline = NULL; } -- Peter Stephenson Software Engineer CSR PLC, Churchill House, Cambridge Business Park, Cowley Road Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070