From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27531 invoked by alias); 7 Nov 2016 02:54:29 -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: 39852 Received: (qmail 4461 invoked from network); 7 Nov 2016 02:54:29 -0000 X-Qmail-Scanner-Diagnostics: from mail-ua0-f180.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.180):SA:0(0.0/5.0):. Processed in 1.122355 secs); 07 Nov 2016 02:54:29 -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,T_DKIM_INVALID autolearn=unavailable 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.180 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=nW8zzkUqAojqlgtAFvj80sJ5e/YhG617jgoBlb5Yq4g=; b=w2TRw9IC19NFcUsT3pnO34gtVq90dChKlKeuoQeUcKJCl091+hW5FysB8fhXct+dN/ 7vhGEKf6v6lFLCmsgRyP3jHGAjy65i/YSdfrjPO379mgAJUztsaf8/DI+mjti06PAntw e6dptce4iTBxVl+80aYHURP6Fzy9I7sVw+6kjbQU63EB1sop4veIl3dlg5nFlk8eXSyp o9x04YWjRWJVEWJV79gcpm5oAfpNU/+vU/VC7ACqphYhr8u4L8qJ6stcwWWpPKbPz4XD v786QpZ7qWmc7RjC4VGwN0cDvve1l1yAh6ZTEKLvGoilpOwEAUf2Stq6VRqVj2/TjaZp Nq6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version; bh=nW8zzkUqAojqlgtAFvj80sJ5e/YhG617jgoBlb5Yq4g=; b=UVRpDglNDOcl/reXosmd2rp4laXUzDfzqpiu5Rb0uYk9/QWkkRl86wu2F4Tj6Yw+KD IrMIHpFpa0+RhBgDtkq2ZxDo79cknqDmeoszgJc3CPXMlYnY1DS0Esffp/QWSdtAGIQf vebuv5Rl8daTJL7AVbeeipeZJjRdCDjp6TWolaMLtfmhu55eJIxYoZcAyW1ksOQF3/LD 9IFemoVLLEom17N2LP5XSDqNU5jFQT7NMuDME6MJh9Ezt6j1zKGS9Q+M90vZYYtdbwuW FWfugroXb7grIXZW3N+O9NjBHc3MwQmHhgBOBguJz/YzVN/1FiFOr9ObJxV7wi5VU5cQ rslw== X-Gm-Message-State: ABUngveDHzELxjzqKMbz1xfcB2nN3bh/ok7ktFqNP3Mp9TNGhQnn71V0ZGThwkzKk9xvOw== X-Received: by 10.176.86.25 with SMTP id y25mr2491920uaa.57.1478487260188; Sun, 06 Nov 2016 18:54:20 -0800 (PST) From: Bart Schaefer Message-Id: <161106185454.ZM21609@torch.brasslantern.com> Date: Sun, 6 Nov 2016 18:54:54 -0800 In-Reply-To: <00b9b00f-0849-93d8-2d1d-eb6e9b810695@thequod.de> Comments: In reply to Daniel Hahler "Re: Better handling of wide glyphs (ask the terminal, not wcwidth)" (Nov 7, 2:09am) References: <3126f405-b1a0-b29c-df2b-a3376aabb702@thequod.de> <161105153708.ZM19128@torch.brasslantern.com> <00b9b00f-0849-93d8-2d1d-eb6e9b810695@thequod.de> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: Better handling of wide glyphs (ask the terminal, not wcwidth) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Nov 7, 2:09am, Daniel Hahler wrote: } } Where would I have to look / poke to do this for the prompt and ZLE only? Mostly in Src/prompt.c, surprisingly enough. There are a couple of routines in Src/utils.c and the code in Src/Zle/complist.c has its own variants for output with color controls. } There it should be mostly about chars that are about to be displayed, } and in this case the "painting in an innocuous spot" is not required at } all (given that those chars are displayed one by one). The problem there is that the prompt formatting code needs to be able to calculate the width before it begins printing, so that it can stop before printing something that won't fit. Otherwise you run into all sorts of auto-margin issues that are already bad enough. And then there's the code used by e.g. zsh-syntax-highlighting which also needs to compute widths in advance in order to populate the array of positions where terminal attributes change. } > a utility to generate such a configuration from the terminal } } How would that work then? Based on the method described above? Yes, basically the way zkbd works except it wouldn't need to be interactive. } Then it would be a pre-generated cache basically?! Yes. } It might be hard to predict what glyphs are being used in the future } though, and it is probably rather big. Yes; if you tried to store them all it'd probably be about the size of the terminfo database multiplied by the number of fonts. But it could omit any glyphs that are only 1 column wide, and you'd just need to generate the tables for the presumably manageable combination of fonts and terminals that a particular user is commonly using. } It's also basically a custom wcwidth(3) implementation then, isn't it? Yes again; but if you can supply the table of glyphs separately then you don't need to update the linked library every time new glyphs or fonts are introduced. (I would not be surprised to find a standards body working on something like this already.)