From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: yet more term.el fixes #2 Date: Wed, 22 Sep 2004 13:47:08 +0900 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: References: <200409220317.i8M3HEGK002410@scanner2.ics.uci.edu> <200409220418.i8M4IJGK005554@scanner2.ics.uci.edu> Reply-To: Miles Bader NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1095828485 28656 80.91.229.6 (22 Sep 2004 04:48:05 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 22 Sep 2004 04:48:05 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 22 06:47:55 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1C9z2o-0004sU-00 for ; Wed, 22 Sep 2004 06:47:55 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C9z8m-0006PA-Ak for ged-emacs-devel@m.gmane.org; Wed, 22 Sep 2004 00:54:04 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1C9z8e-0006Ny-2G for emacs-devel@gnu.org; Wed, 22 Sep 2004 00:53:56 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1C9z8d-0006NE-Bg for emacs-devel@gnu.org; Wed, 22 Sep 2004 00:53:55 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C9z8d-0006Mn-8f for emacs-devel@gnu.org; Wed, 22 Sep 2004 00:53:55 -0400 Original-Received: from [202.32.8.214] (helo=tyo201.gate.nec.co.jp) by monty-python.gnu.org with esmtp (Exim 4.34) id 1C9z2I-0000cH-N3; Wed, 22 Sep 2004 00:47:23 -0400 Original-Received: from mailgate4.nec.co.jp (mailgate54.nec.co.jp [10.7.69.195]) by tyo201.gate.nec.co.jp (8.11.7/3.7W01080315) with ESMTP id i8M4lIA12638; Wed, 22 Sep 2004 13:47:18 +0900 (JST) Original-Received: (from root@localhost) by mailgate4.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id i8M4lH700849; Wed, 22 Sep 2004 13:47:17 +0900 (JST) Original-Received: from edtmg05.lsi.nec.co.jp ([10.26.17.202]) by mailsv5.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with ESMTP id i8M4lAN05854; Wed, 22 Sep 2004 13:47:10 +0900 (JST) Original-Received: from mcsss2.ucom.lsi.nec.co.jp (localhost [127.0.0.1]) by edtmg05.lsi.nec.co.jp (8.12.10/8.12.10) with ESMTP id i8M4l9vr000888; Wed, 22 Sep 2004 13:47:09 +0900 (JST) Original-Received: from mctpc71 (mctpc71.ucom.lsi.nec.co.jp [10.30.118.121]) by mcsss2.ucom.lsi.nec.co.jp (8.12.10/8.12.8/EDcg v2.01-mc/1046780839) with ESMTP id i8M4l8wt025134; Wed, 22 Sep 2004 13:47:08 +0900 (JST) Original-Received: by mctpc71 (Postfix, from userid 31295) id 503353C0; Wed, 22 Sep 2004 13:47:08 +0900 (JST) Original-To: Dan Nicolaescu System-Type: i686-pc-linux-gnu Blat: Foop In-Reply-To: <200409220418.i8M4IJGK005554@scanner2.ics.uci.edu> (Dan Nicolaescu's message of "Tue, 21 Sep 2004 21:18:16 -0700") Original-Lines: 35 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:27412 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:27412 Dan Nicolaescu writes: > Looking closer, the characters > 158 decimal have char-width 4 in my > setup. > > Use this to print all the widths: Hmmm, using that code I get simular (odd) results: the result of `char-width' seems to be completely unrelated to the actual displayed width of the characters -- some values are displayed as a single column character, but have a `char-width' value of 4, and some are displayed as a 4-column escape-sequence, but have a `char-width' value of 1!! Here's a version that uses `decode-coding-string' to get correct results; probably term.el should be using something like that: (defun print-width () (interactive) (let ((i 0)) (while (< i 256) (let ((decoded (decode-coding-string (string i) 'iso-8859-1))) (insert (format "%d %d %s\n" i (string-width decoded) decoded))) (setq i (1+ i))))) Using this, all the char-width values match the displayed representation. When simply inserting raw character values in to the buffer, it seems that some sort of default decoding takes place at insert/display time, but an equivalent default decoding is not done by `char-width'; whether that represents a bug, and if so, where, I don't know, but I think it's probably always safer to be explicit as in the above code. -Miles -- The secret to creativity is knowing how to hide your sources. --Albert Einstein