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: Mon, 23 Dec 2002 15:40:11 +0900 (JST) Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <200212230640.PAA12591@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 1040625679 28900 80.91.224.249 (23 Dec 2002 06:41:19 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 23 Dec 2002 06:41:19 +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 18QMH7-0007Vz-00 for ; Mon, 23 Dec 2002 07:41:17 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18QMK3-0002Hx-00 for ; Mon, 23 Dec 2002 07:44:19 +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 18QMGg-0000G4-00 for emacs-devel@quimby.gnus.org; Mon, 23 Dec 2002 01:40:50 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18QMGK-0000Fx-00 for emacs-devel@gnu.org; Mon, 23 Dec 2002 01:40:28 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18QMGI-0000Fl-00 for emacs-devel@gnu.org; Mon, 23 Dec 2002 01:40:27 -0500 Original-Received: from tsukuba.m17n.org ([192.47.44.130]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18QMGG-00006i-00; Mon, 23 Dec 2002 01:40:24 -0500 Original-Received: from fs.m17n.org (fs.m17n.org [192.47.44.2])gBN6eCk24241; Mon, 23 Dec 2002 15:40:12 +0900 (JST) (envelope-from handa@m17n.org) Original-Received: from etlken.m17n.org (etlken.m17n.org [192.47.44.125]) gBN6eBR09983; Mon, 23 Dec 2002 15:40:11 +0900 (JST) Original-Received: (from handa@localhost) by etlken.m17n.org (8.8.8+Sun/3.7W-2001040620) id PAA12591; Mon, 23 Dec 2002 15:40:11 +0900 (JST) Original-To: d.love@dl.ac.uk In-reply-to: (message from Dave Love on 19 Dec 2002 22:35:46 +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:10321 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:10321 In article , Dave Love writes: > Kenichi Handa writes: >> Yes, it's better for Emacs, but not for the other programs >> (e.g. ispell). And such Emacs Lisp applications that use >> wrong coding system should be fixed anyway. > Yes, my point is that ispell should be fixed, but people are avoiding > the issue. I don't think the program `ispell' itself should be fixed. When it requires a latin-1 input, sending an ESC sequence is not good. We can't blame ispell for not interpreting that ESC sequence properly. 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. > Other programs allow users to set a coding system for some > file and they sometimes set it wrongly; I think I mentioned BBDB > initially as a real example. Then BBDB should call select-safe-coding-system before siliently using a specified coding system. >> > What concept do you mean, exactly? >> >> For instance, the MIME charset iso-8859-1 can encode Latin-1 >> chars only, and it's stateless, no escape sequences. > But the issue is what happens when you tell them to encode something > they can't (safely) encode. They either have to produce some > more-or-less arbitrary result or to arrange to signal an error. Yes, or course. But, I think producing "?" is less surprising than produing an ESC sequence. --- Ken'ichi HANDA handa@m17n.org