From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Hin-Tak Leung Newsgroups: gmane.emacs.devel Subject: Re: a few MULE criticisms Date: Thu, 15 May 2003 03:03:23 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <3EC2F56B.1000503@yahoo.co.uk> References: <3EC2A0FA.1040007@yahoo.co.uk> <200305142155.h4ELtMjX019837@rum.cs.yale.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1052963861 17105 80.91.224.249 (15 May 2003 01:57:41 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 15 May 2003 01:57:41 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu May 15 03:57:39 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19G803-0004Rh-00 for ; Thu, 15 May 2003 03:57:39 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19G87g-0000PT-00 for ; Thu, 15 May 2003 04:05:33 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 19G81H-0001Ba-05 for emacs-devel@quimby.gnus.org; Wed, 14 May 2003 21:58:55 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 19G80i-0000U3-00 for emacs-devel@gnu.org; Wed, 14 May 2003 21:58:21 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 19G80E-0007Sq-00 for emacs-devel@gnu.org; Wed, 14 May 2003 21:57:51 -0400 Original-Received: from smtp015.mail.yahoo.com ([216.136.173.59]) by monty-python.gnu.org with smtp (Exim 4.10.13) id 19G80A-0007Au-00 for emacs-devel@gnu.org; Wed, 14 May 2003 21:57:46 -0400 Original-Received: from m11-mp1.cvx1-a.cam.dial.ntli.net (HELO yahoo.co.uk) (hintak?leung@62.253.144.11 with plain) by smtp.mail.vip.sc5.yahoo.com with SMTP; 15 May 2003 01:57:44 -0000 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en, en-us Original-To: Stefan Monnier In-Reply-To: <200305142155.h4ELtMjX019837@rum.cs.yale.edu> X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:13887 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:13887 Stefan Monnier wrote: > I have no knowledge of any non-latin script, so could you explain > to me how Emacs-19.34 can be used to edit in a character-set larger > than 256 chars ? It is a very old system (tradition? dated back to emacs-18). The principle is essentially putting emacs in -nw and 8-bit display mode inside a customized terminal emulator, and let the terminal emulator handles how keystrokes are translated into characters inserted into the emacs buffer, and what fonts are used for the display. This mechanism isn't exactly specific to emacs, but any editor or indeed any application (pine, lynx, etc) that would be happy within such an environment. There are other less important subtleties, like adjusting the movements of cursor in steps of suitable character units, rather than bytes, which made emacs the better choice for such "embedded" use. > Emacs-20.1 also had an option to run in unibyte mode, although > it didn't have the --unibyte argument. etc/NEWS for Emacs-20.1 says: > > [...] > > You can disable multibyte character support as follows: > > (setq-default enable-multibyte-characters nil) > > [....] > > Note that Emacs-20.1 and 20.2 turned out to have many problems, > so very few people are still using them (much fewer than 20.3 > or 19.34). Thanks for pointing this out (this is still a very good learning experience even though it is about 8 years late...). For a few years the general(?) consesus was either (a) don't upgrade, (b) switch to other X-based mechanism. I haven't had any experience with i18n support in X nor localised X, but I heard that they are somewhat usable. The advantage of that approach is that it is available to all X-clients (browsers, terminal emulators, editors). As I previously said out, my main criticism of using MULE is that it can't suggest the next character by association or by fuzzy match. The same criticism doesn't seem to apply to i18n X support - some l10n X or i18n X system indeed ships large dictionaries with the system. I am not sure about Chinese support, but Wnn and Canna (both quite well-known and quite big Japanese dictionaries) are shipped with some commercial and even open-source unix/unix-like systems.