From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stefan Monnier" Newsgroups: gmane.emacs.devel Subject: Re: a few MULE criticisms, cemacs, & current emacs segfaults by changes in GNU ld. Date: Wed, 14 May 2003 17:55:21 -0400 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200305142155.h4ELtMjX019837@rum.cs.yale.edu> References: <3EC2A0FA.1040007@yahoo.co.uk> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1052950049 9270 80.91.224.249 (14 May 2003 22:07:29 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 14 May 2003 22:07:29 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu May 15 00:07:27 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 19G4P3-0002Ni-00 for ; Thu, 15 May 2003 00:07:13 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19G4Wc-0006ka-00 for ; Thu, 15 May 2003 00:15:02 +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 19G4P5-0003sZ-01 for emacs-devel@quimby.gnus.org; Wed, 14 May 2003 18:07:15 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 19G4Gx-0008Lc-00 for emacs-devel@gnu.org; Wed, 14 May 2003 17:58:51 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 19G4Dr-0007Zi-00 for emacs-devel@gnu.org; Wed, 14 May 2003 17:55:40 -0400 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 19G4Db-0007X1-00; Wed, 14 May 2003 17:55:23 -0400 Original-Received: from rum.cs.yale.edu (localhost [127.0.0.1]) by rum.cs.yale.edu (8.12.8/8.12.8) with ESMTP id h4ELtMx6019839; Wed, 14 May 2003 17:55:22 -0400 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.12.8/8.12.8/Submit) id h4ELtMjX019837; Wed, 14 May 2003 17:55:22 -0400 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Original-To: Hin-Tak Leung Original-cc: Richard Stallman 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:13881 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:13881 > This is not meant to be a flame - Mr Stallman asked me why I would rather > continue to use emacs 19.34 (and fixes its problems) in combination > with an old cemacs elisp script instead of using MULE, and I am writing > this in the hope that MULE will satisfy my editing needs one day. I > am native Chinese, and can also do a small amount of Japanese, so > my experience is probably quite representative. 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 ? > (4) The inability to process part of a file in one encoding and > save it as a binary stream: This might be possible in MULE, but > I can't work out how - MULE seems to insist that I save or > convert documents into its internal representation. That is true but not fundamentally bothersome, when you think about it: the way the file is internally represented is not important. What matters is what you see on screen and what you get when you save the file (i.e. mostly that the unedited parts of the file are preserved bit-for-bit). Emacs-21 is much better at "preserving bytes that we don't understand". > e.g. I have a file, > part of which is in GB2312, part in JIS-euc, and part BIG5, separated > by clear ASCII markers. I would like to edit the different parts This is indeed not well supported. But you can try to read it once with GB2312 (at which point the BIG5 part will look like garbage, but it should be preserved AFAIK, if not you might want to report it as a bug). You can later re-read the file with a BIG5 encoding (at which point the GB2312 part will look like garbage, ...). > individually, and without breaking the others, and without converting > to MULE's internal format or a common one like UTF-8. I don't think > it is difficult to implement, but it is more like the MULE developers > think they know my needs better than I do, and insist that I do > things their way. Emacs could support the situation you describe, but nobody has bothered to write the code for it AFAIK. It can all be done in elisp, tho. > As for the portability problem with the elisp script cemacs.el > (the origin of the whole thread) to current emacs versions, I have been > looking deeper into the documentation of current emacs and just > found my answer; starting current emacs with the --unibyte option > would do. I also looked a bit further - apparently the --unibyte option > was not available before emacs 20.3, so cemacs.el had indeed been > broken for about 3 years between 1995 and 1998. As a result, cemacs's > README contains a warning that it doesn't run under emacs 20+, > and a later fork+enhancement of it even contains codes for > version checking and abort under emacs 20+. I'll write > to the author of cemacs to rectify that. 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). Stefan