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: iso-8859-1 and non-latin-1 chars Date: Wed, 25 Dec 2002 22:05:29 +0900 (JST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200212251305.WAA15177@etlken.m17n.org> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Trace: main.gmane.org 1040821584 3285 80.91.224.249 (25 Dec 2002 13:06:24 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 25 Dec 2002 13:06:24 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18RBEs-0000qr-00 for ; Wed, 25 Dec 2002 14:06:22 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18RBIu-0001mp-00 for ; Wed, 25 Dec 2002 14:10:33 +0100 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 18RBEf-0001A6-01 for emacs-devel@quimby.gnus.org; Wed, 25 Dec 2002 08:06:09 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18RBEI-00018H-00 for emacs-devel@gnu.org; Wed, 25 Dec 2002 08:05:46 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18RBEG-00016G-00 for emacs-devel@gnu.org; Wed, 25 Dec 2002 08:05:45 -0500 Original-Received: from tsukuba.m17n.org ([192.47.44.130]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18RBEE-0000wc-00; Wed, 25 Dec 2002 08:05:42 -0500 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2])gBPD5Uk26244; Wed, 25 Dec 2002 22:05:30 +0900 (JST) (envelope-from handa@m17n.org) Original-Received: from etlken.m17n.org (etlken.m17n.org [192.47.44.125]) gBPD5UR20217; Wed, 25 Dec 2002 22:05:30 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id WAA15177; Wed, 25 Dec 2002 22:05:29 +0900 (JST) Original-To: d.love@dl.ac.uk Sent-via: d.love@dl.ac.uk Sent-via: rms@gnu.org, emacs-devel@gnu.org, kstevens@ichips.intel.com In-reply-to: (message from Dave Love on 23 Dec 2002 12:27:58 +0000) 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 Original-cc: kstevens@ichips.intel.com 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:10340 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:10340 In article , Dave Love writes: > Kenichi Handa writes: >> I don't think the program `ispell' itself should be fixed. > I meant ispell.el, though it is unfortunate that we don't have a > spelling program that deals with multibyte encodings as far as I know. Sure. Though, I see this mail in linux-utf8 mailing list. On Wed Feb 6 16:18:23 2002 +0300 Maxim N. Bychkov wrote: >>Good day. >> >>Could anybody explain me how to use unicode symbols in Ispell? >> >>Thank you in advance. >> > >AFAIK you can't. But some ispell dictionaries, like >esperanto, have a hack for command line -Tutf8 option to >spellcheck UTF-8 text. >> But, ispell.el should be made more robust. When it finds an >> unencodable character in a word, perhaps, it should show the >> word as a misspelled word to a user instead of sending it to >> the ispell program. > Yes, that's what I've implemented for flyspell. The problem is that > ispell.el sends a whole line to the subprocess (unlike flyspell). > Also it doesn't use the Emacs syntax table to decide what's a word. But, I think it's not that difficult to fix this behaviour so that it breaks a line at an unencodable word. >> Then BBDB should call select-safe-coding-system before >> siliently using a specified coding system. > No, it should use a general coding system to store all > text. If that is possible (i.e. users allows that), yes. But, why calling select-safe-coding-system is not good? > I implemented that, but people have used inappropriate > values (either by setting the relevant variable or via > `file-coding-system-alist') and there could be problems in > the transition to the new version. Those people should have already encountered a problem as I wrote before because they can't decode a text back with the same coding system. By the way, the function choose_write_coding_system () checks a coding system specified in file-coding-system-alist by select-safe-coding-system. --- Ken'ichi HANDA handa@m17n.org