From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Jason Rumney Newsgroups: gmane.emacs.devel Subject: Re: 8859 unification and Emacs' ChangeLog files Date: 03 Apr 2003 21:38:25 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <848yuy3xab.fsf@lucy.is.informatik.uni-duisburg.de> <200303310045.JAA14857@etlken.m17n.org> <8465pvo793.fsf@lucy.is.informatik.uni-duisburg.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: main.gmane.org 1049402590 19951 80.91.224.249 (3 Apr 2003 20:43:10 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 3 Apr 2003 20:43:10 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Apr 03 22:43:09 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 191BYD-0005Bd-00 for ; Thu, 03 Apr 2003 22:43:09 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 191BZw-0008KB-00 for ; Thu, 03 Apr 2003 22:44:56 +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 191BWS-0007nd-07 for emacs-devel@quimby.gnus.org; Thu, 03 Apr 2003 15:41:20 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 191BVf-0007aa-00 for emacs-devel@gnu.org; Thu, 03 Apr 2003 15:40:31 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 191BV9-0007Tz-00 for emacs-devel@gnu.org; Thu, 03 Apr 2003 15:40:00 -0500 Original-Received: from server0011.freedom2surf.net ([194.106.56.14] helo=server0027.freedom2surf.net) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.10.13) id 191BV5-0007Hi-00 for emacs-devel@gnu.org; Thu, 03 Apr 2003 15:39:55 -0500 Original-Received: from nyaumo.jasonr.f2s.com ([195.137.103.251]) h33KdrRT026553 for ; Thu, 3 Apr 2003 20:39:53 GMT Original-Received: from nyaumo.jasonr.f2s.com (localhost [127.0.0.1]) by nyaumo.jasonr.f2s.com (Postfix) with ESMTP id 0226A4A7F3 for ; Thu, 3 Apr 2003 21:38:25 +0100 (BST) Original-To: emacs-devel@gnu.org In-Reply-To: <8465pvo793.fsf@lucy.is.informatik.uni-duisburg.de> Original-Lines: 31 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 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:12876 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:12876 kai.grossjohann@gmx.net (Kai Gro=DFjohann) writes: > But if all Emacs developers enable unify-8859-on-decoding-mode, then > this is not a problem anymore. It is still a problem, because some users will end up saving all Latin characters unified to Latin-1 while others will save all unified to Latin-2 etc. So there will be a lot of unnecessary changed lines in each checkin. > Or the ChangeLog files could be stored as UTF-8. This could certainly work, if we think UTF-8 support in Emacs now is good enough to handle it reliably. > Of course, there might be other files where iso-8859 characters might > be present in different encodings. Is it right to say that these > files must be encoded in iso-2022 or in emacs-mule, because no other > encodings distinguish between Latin-1 =E4 and Latin-2 =E4, say? Yes, many of the files in leim, lisp/international and lisp/language need to make the distinction between different Latin charsets. > If I understand correctly, Emacs 22 will automatically unify all > iso-8859 charsets, so the same ChangeLog problem will occur there, > right? Or is Emacs 22 going to enable distinguishing between Latin-1 > =E4 and Latin-2 =E4 for iso-2022 files somehow? I think the future plan is to support keeping the distinction (somehow) even though the internal representation is unicode.