From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kenichi Handa Newsgroups: gmane.emacs.devel Subject: Re: a few MULE criticisms, cemacs, & current emacs segfaults by changes in GNU ld. Date: Thu, 15 May 2003 10:18:39 +0900 (JST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200305150118.KAA04234@etlken.m17n.org> References: <3EC2A0FA.1040007@yahoo.co.uk> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: multipart/mixed; boundary="Multipart_Thu_May_15_10:18:39_2003-1" X-Trace: main.gmane.org 1052961581 9100 80.91.224.249 (15 May 2003 01:19:41 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 15 May 2003 01:19: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:19: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 19G7PG-0002Mc-00 for ; Thu, 15 May 2003 03:19:38 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19G7Wt-0008Vv-00 for ; Thu, 15 May 2003 03:27:32 +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 19G7Qk-0007eT-01 for emacs-devel@quimby.gnus.org; Wed, 14 May 2003 21:21:10 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 19G7PW-0006ZG-00 for emacs-devel@gnu.org; Wed, 14 May 2003 21:19:54 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 19G7Ow-0004j9-00 for emacs-devel@gnu.org; Wed, 14 May 2003 21:19:22 -0400 Original-Received: from tsukuba.m17n.org ([192.47.44.130]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 19G7OP-0003OY-00; Wed, 14 May 2003 21:18:45 -0400 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2])h4F1Ieo06492; Thu, 15 May 2003 10:18:40 +0900 (JST) (envelope-from handa@m17n.org) Original-Received: from etlken.m17n.org (etlken.m17n.org [192.47.44.125]) h4F1IeA06865; Thu, 15 May 2003 10:18:40 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id KAA04234; Thu, 15 May 2003 10:18:39 +0900 (JST) Original-To: hintak_leung@yahoo.co.uk In-reply-to: <3EC2A0FA.1040007@yahoo.co.uk> (message from Hin-Tak Leung on Wed, 14 May 2003 21:03:06 +0100) User-Agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.2.92 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) Original-cc: rms@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:13885 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:13885 --Multipart_Thu_May_15_10:18:39_2003-1 Content-Type: text/plain; charset=US-ASCII In article <3EC2A0FA.1040007@yahoo.co.uk>, Hin-Tak Leung writes: > 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. Thank you for the report. At first, as far as I know, cemacs.el is a small program written by that does just these things: o make emacs 19 use standard-display-8bit o rebind forward-char, delete-char, etc to functions that pay attention to 8-bit chars. And, it works only in tty mode under a chinese terminal, e.g. cxterm. Correct? Or, are we talking about the different program? If so, please send me your version of cemacs.el. If we are talking about the same program, the current Emacs doesn't need it. You can start emacs under cxterm by: % LANG=zh emasc -nw Or, start emacs with "-nw" and C-x RET t euc-cn RET C-x RET k euc-cn RET. Now, Emacs should display GB2312 characters correctly, and you can also use the input methods of cxterm. If you are using cxterm with Big5 mode, do this instead: % LANG=zh_CN.big5 emacs -nw > (1) Associations: the ability to let the user choose the next possible > associated characters. [...] > 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. I think this should be implemented by extending abbrev-mode so that it can associate an abbreviation with multiple words/phrases (is it possible already?) > (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. When you type TAB while you are using an input method, Emacs shows the full list. But, the method used in cxterm is not implemented, it's not easy. > (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. ??? Why is it difficult? You just have to create a new leim file, and load it. > (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. There are two ways for dealing with such a situation. o use file-name-handler o make a special coding system The attached is a quick hack for the latter. When you load mixed-coding.el, you can read the file sample.txt by C-x RET c mixed-coding RET C-x C-x sample.txt RET, and save that file simply by C-x C-s. Separator lines are highlighted in a buffer. --- Ken'ichi HANDA handa@m17n.org --Multipart_Thu_May_15_10:18:39_2003-1 Content-Type: application/octet-stream; type=tar+gzip Content-Disposition: attachment; filename="mixed-coding.tar.gz" Content-Transfer-Encoding: base64 H4sIAM3pwj4AA+1XzY7bNhD2NXyKgXowta1c2WvZx6K5pCnQU65BEFqibbUSpVD02gH6OEbzAL31 VjS3HvoQfYS+QIc/kqVN1rspnKJF+AG7XnKG8/PNDM0t8wPPorTKcrH5cvRxEMfzeLlM8HMWTxfz 3meHUbxcLOJkkcQx6k1n18l8BMlHimeAXaOYBBhtmcjYGb375P9TlP369xcTXlzKRzyN48Wg7oP6 z5ezrv7z5bWufzJLFiOILxXAOXzi9acZX98gAf3SRw2vmWSqkhEr8kYRgDGlwYsnj2fX09nkKoAJ 8F0apSJEEQCKHj99kljBKt8k3fa3T59FqHk68n0dhiEh2mtaiUbd5VfyDT/UaIaWrEbNlOko4LMx LVi5yhjQQwjUCiB4/pwGuMI0cBdXYRCaEO5JSqv+GJyLh615lG6ZbLhqdDAFV0BpASIvQpdkVmlr QHlxZzLGn1XvbLRWdRJW/XWjeBlttDTNJKC9EMaDCDR1j2i+BioqBQUujEEUvYICOi29fQpruI+S SiKpvHwF3Jh41J7XbDZm08LEW7Ts7MQwu7pqFFaJ6Q1xw2VeCZ2a6QjasBuOwkbJPFUosUwJJmW1 j1Slq2v06yoXmCX9vPtTW3DEWp7QTyu0iVn/vQrg3n6bFxyo5Eg6k+k2Wldyz2R2vru0DRiX1Q3X tFp3nY5uPIWWdA7oLg6d+3qnIsUPKqplVXOpXreKK8xJCKvb7nGR4Qo5NszDeM1SDuNtvtkW+KMu YBF5YWKTrzB9Zw7bw+Zry61bgeMGb1lw3Bte3+PHarlkTWf0KgA98o2CJU0xJPJs77e95wqFV6nt YecNtIWwC1h3uOU9MhHa0Ta/jGIInX1NRRuoC85MT0/51OMmTiN2kq7Nb/N2hrMBE+15uqmwrfWk OYWozLtGtvPFcF6Go75reIb91+PNHYg6I0zfcq7775xEbPu9zBXvT+JaViWoKjxdWqsdsprupORo GBdrLsNehG4LM+GCI7U8EnzfbgZwhQHXV0F74FShGrQrcy+JBrvXLVtSzZ4zEzW7lRsnHUwb4gMY /G9eBe9OGhcP7JpPfLoezNM/nCDbEQTr9gMfHiFDdYjhq+8IBN8gZ0idETnnzSQg2hCBl9gL/a9h fMp8cfczwURAb389NjrDyb1foe7wrYl+7+F3p97cEB/6/hu8/xtW1gWfqIO66Bvznvd/PL1enN7/ yynqz+fx3L///w08MyUH/QABvCrhZb8hxu3U2+GZEGL/BSDk7Z+//EaIfvUT8ubrnwQh7qlPyPHn 41/H34+/Hv/48G708PDw8PDw8PDw8PDw8PDw8PDw8PDw8LgE/gbnghPxACgAAA== --Multipart_Thu_May_15_10:18:39_2003-1 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://mail.gnu.org/mailman/listinfo/emacs-devel --Multipart_Thu_May_15_10:18:39_2003-1--