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: a few MULE criticisms, cemacs, & current emacs segfaults by changes in GNU ld. Date: Wed, 14 May 2003 21:03:06 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <3EC2A0FA.1040007@yahoo.co.uk> 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 1052943236 6335 80.91.224.249 (14 May 2003 20:13:56 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 14 May 2003 20:13:56 +0000 (UTC) Cc: Richard Stallman Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed May 14 22:13:55 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 19G2ck-0001Zp-00 for ; Wed, 14 May 2003 22:13:14 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19G2kH-0005eN-00 for ; Wed, 14 May 2003 22:21:01 +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 19G2VQ-00010G-0A for emacs-devel@quimby.gnus.org; Wed, 14 May 2003 16:05:41 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 19G2Te-0008UP-00 for emacs-devel@gnu.org; Wed, 14 May 2003 16:03:50 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 19G2So-0006vT-00 for emacs-devel@gnu.org; Wed, 14 May 2003 16:03:02 -0400 Original-Received: from smtp013.mail.yahoo.com ([216.136.173.57]) by monty-python.gnu.org with smtp (Exim 4.10.13) id 19G2OA-0004Cg-00 for emacs-devel@gnu.org; Wed, 14 May 2003 15:58:10 -0400 Original-Received: from m140-mp1.cvx1-b.cam.dial.ntli.net (HELO yahoo.co.uk) (hintak?leung@62.253.148.140 with plain) by smtp.mail.vip.sc5.yahoo.com with SMTP; 14 May 2003 19:58:00 -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: emacs-devel@gnu.org 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:13871 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:13871 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. (1) Associations: the ability to let the user choose the next possible associated characters. In English, "Search" is often followed by "engine" "for" or "through". In Chinese, When I type "Leung" (not in common sentence vocabulary, but it is a common surname), it is almost certain that I would follow with the rest of my name. Another example in Chinese, the simplest one character word "one", is often followed by a few specific characters to make up small compound units which means "definitely", "a few", "all", "generally", "once", "unified", "together", "one sided", etc. It saves a lot of typing by a factor or 2 or 3 in Chinese - It is 3 letters (for "Leung") then "1" (for choice), instead of the 3+5+4 for the shortest method (ChangJie). The input of many common phrases which would normally requires 10+ key strokes, can be shorten by associations. The facility is available in localised version of MacOS, in English MacOS's CJK add-on's (I have used the latter, and seen a Japanese friend using the former), and available in 3rd party add-ons to English MS Windows for many years. This would most certainly require extending MULE with the ability of loading distionaries of commonly used phrases in various languages. And will make the leim package a lot bigger. (2) Hints: quite similiar to (1), e.g. sometimes I can't quite remember the code for "Leung", but vaguely know it is "e*f" in ChangJie. (it is actually 'eif'). On just about any other systems (MacOS's CJK extensions, etc), the full list is displayed and it narrows down as the user types, so the user can select the correct one visually if he can't remember the exact code. On Cxterm, one can do 'e?f' or 'e??f' to obtain a list of matches. (3) new input methods, and per-user input methods: adding new input mapping methods on a per-user basis and make that the default. I know this is possible in MULE - but the procedure is not in the obvious places. There are new methods coming out, e.g. new ones developed in view of handhelds, which only requires the key-pad numeric keys. And there are personal per-user needs e.g. I might like an enhanced ChangJie method, which includes a special short-hand for my own name, to over-ride the system one. (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. 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 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. 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. And lastly, I don't need to keep on porting emacs 19.34 forward anymore - However, the answer: adding LDFLAGS='-z nocombreloc', should be applied to current version of emacs's configure to stop it from being broken by recent change to default 'combreloc' in GNU ld. I would like to thank everybody for the work on emacs and the other works from FSF. -------- Original Message -------- Subject: Re: Re: emacs-19.34 segfauls when built with Xfree 4.3.0 (glibc 2.3.x,gcc 3.2) Date: Wed, 14 May 2003 09:48:09 -0400 From: Richard Stallman Reply-To: rms@gnu.org In contrast,, we might be interested in trying to fix this problem I want to use a elisp script called cemacs (for Chinese inputs) but unfortunately the inclusion the MULE (Multi-lingual Extension) since version 20 has broken it. if you send a bug report with a precise complete test case. We are certainly interested in improving MULE. Could you write to emacs-devel@gnu.org and tell us why specifically MULE is not as good as cemacs for your usage?