From xemacs-m  Thu Dec  5 20:02:45 1996
Received: from etlpost.etl.go.jp (etlpost.etl.go.jp [192.31.197.33]) by xemacs.cs.uiuc.edu (8.8.3/8.8.3) with SMTP id UAA08049 for <xemacs-beta@xemacs.org>; Thu, 5 Dec 1996 20:02:39 -0600 (CST)
Received: from etlpom.etl.go.jp by etlpost.etl.go.jp (8.6.9+2.4W/2.7W)
	id LAA20027; Fri, 6 Dec 1996 11:02:35 +0900
Received: by etlpom.etl.go.jp (4.1/6.4J.6-ETLpom.MASTER)
	id AA23042; Fri, 6 Dec 96 11:02:34 JST
Received: by etlken.etl.go.jp (SMI-8.6/6.4J.6-ETL.SLAVE)
	id LAA06357; Fri, 6 Dec 1996 11:03:38 +0900
Date: Fri, 6 Dec 1996 11:03:38 +0900
Message-Id: <199612060203.LAA06357@etlken.etl.go.jp>
From: Kenichi Handa <handa@etlken.etl.go.jp>
To: mule@etl.go.jp
Cc: mule@etl.go.jp, xemacs-beta@xemacs.org, brewin@Eng.Sun.COM,
        Teruhiko.Kurosaka@Japan.Sun.COM
In-Reply-To: <199612020753.XAA19995@xemacs.eng.sun.com> (message from Martin
	Buchholz on Sun, 1 Dec 1996 23:53:08 -0800)
Subject: Re: mule API of Emacs and XEmacs (Re: caesar-region)

   Date: Sun, 1 Dec 1996 23:53:08 -0800
   From: Martin Buchholz <mrb@Eng.Sun.COM>

   Ben Wing did the original XEmacs Mule implementation.  I am currently
   maintaining it.
   (charset-dimension) gives information on the encoding space, not display
   space, e.g.
   (eq (charset-dimension 'japanese) 2) means that you need 2 octets to encode
   a character, which means you need to pass 2 octet arguments to (make-char)

I see.

   On the other hand, (charset-columns) gives the display width (in
   character cells) of the character on a tty.  This is not necessarily
   the same as (charset-chars), but they are often the same in practice.
   On an X display, (charset-columns) gives a better approximation to the
   actual displayed width of the character (especially if fonts are
   chosen with this assumption in mind) than to assume all characters are
   the same size, so (charset-columns) is used by the column-manipulating
   functions like (current-column).  I think (charset-width) should refer
   to the actual displayed width of a character, but that would be
   undefined since this is font-dependent.  So we are better off not
   having a (char-width) or (charset-width) function at all.  So I like
   XEmacs' decision to have (charset-dimension) and (charset-columns),
   but not (charset-width).  

   But I am willing to change XEmacs' (charset-columns) function name to
   (charset-width), for compatibility reasons.

I personally agree that the name charset-columns is better, more
clear.  But, Emacs already uses "width" for column numbers
(e.g. screen-width), and for pixel width, it used "pixel-width"
(e.g. frame-pixel-width).  So, I prefer to keep using "width" for
column numbers.

   I agree that we should use international standards to name charsets
   and coding-systems.  Can't we just copy the names from the relevant
   RFC's?  But I object to the prefixes `coding-system' and `charset-',
   although I can be swayed on this point.  An interface that may be
   common to both emacsen might be (get-charset):

As for charset and coding system names, I'll discuss with RMS again.
Please wait a while.

---
Ken'ichi HANDA
handa@etl.go.jp

