From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Karl Eichwalder Newsgroups: gmane.emacs.devel Subject: Re: Several serious problems Date: Wed, 24 Jul 2002 06:43:01 +0200 Sender: emacs-devel-admin@gnu.org Message-ID: References: <200207221711.g6MHBZo02496@aztec.santafe.edu> <200207240325.g6O3Pkt04913@aztec.santafe.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1027486998 32647 127.0.0.1 (24 Jul 2002 05:03:18 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 24 Jul 2002 05:03:18 +0000 (UTC) Cc: handa@etl.go.jp, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17XEIs-0008UJ-00 for ; Wed, 24 Jul 2002 07:03:14 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17XEXX-0001AQ-00 for ; Wed, 24 Jul 2002 07:18:23 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17XEJ4-0004Lr-00; Wed, 24 Jul 2002 01:03:26 -0400 Original-Received: from dns.franken.de ([193.175.24.33] helo=elvis.franken.de) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17XEIB-0004Kh-00; Wed, 24 Jul 2002 01:02:31 -0400 Original-Received: from uucp by elvis.franken.de with local-rmail (Exim 3.22 #1) id 17XEI5-0001qL-00; Wed, 24 Jul 2002 07:02:25 +0200 Original-Received: by tux.gnu.franken.de (Postfix, from userid 270) id 8FF5AA43A1; Wed, 24 Jul 2002 06:43:01 +0200 (CEST) Original-To: rms@gnu.org In-Reply-To: <200207240325.g6O3Pkt04913@aztec.santafe.edu> (Richard Stallman's message of "Tue, 23 Jul 2002 21:25:46 -0600 (MDT)") Original-Lines: 86 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.3.50 (i686-pc-linux-gnu) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:6006 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:6006 Richard Stallman writes: > Often it's getting even worse: Emacs proposes a > "secure" encoding and when users go for it, all looks well until you > want to process such a file with TeX... > > I am not really sure what that means--would you please explain? We discussed the issue several times (e.g. under the subject "lisp/ChangeLog coding system"); here is a good remark by Stephen J. Turnbull. Yes, that's a different from your problem, but it's cause by the same implementation concept (enabling unification might cure most of these problems -- thus it's very important to release an Emacs with this feature, all released Emacs 21.x versions destroy user files at random...): From: "Stephen J. Turnbull" Subject: Re: lisp/ChangeLog coding system To: "Stefan Monnier" Cc: Eli Zaretskii , emacs-devel@gnu.org Date: 29 Apr 2002 20:28:55 +0900 >>>>> "Stefan" == Stefan Monnier writes: >> One aspect is making better guesses about desired coding >> systems. Stefan> I'm not sure what kind of improvements you're thinking Stefan> about. Well, in the version (mid-January, maybe?) of GNU Emacs I have, when I tried saving a buffer with mixed ascii, latin-1, and latin-2 in it, it gave me an abominably long list of coding systems including mule internal, all the -with-esc systems, and iso-2022-jp-2. But all of the characters used in the buffer are in ISO-8859-2, it's just Mule making false distinctions. At the very least, the defaults in Emacs should be to identify identical characters (eg, those from the Latin-## subsets) and to distinguish those where unification is controversial (the Han ideographs). Stefan> non-MIME coding-systems should be in the "unlikely" list, tho. There is no unique "the unlikely list". For example, if I were Croatian, I probably would want the buffer described above saved in ISO-8859-2 without being asked, but a German would probably want to save it in UTF-8 (or maybe ISO-2022-7 if she were an Emacs developer), or be queried, defaulting to ISO-8859-2. And some of the "universal" coding systems (UTF-32, mule internal, all the -with-esc systems) should probably not even be offered to most users; they should have to ask for them by name. But people with special needs should be able to configure them for regular use. And what's a "non-MIME coding system"? AFAIK MIME has nothing to do with coding systems except that the notation "the preferred MIME name" is a useful convention. But KOI8-R and all the Windows-125x sets are MIME registered. Stefan> Looking at the README, I have the impression that most of Stefan> the functionality is already part of the Emacs CVS code Stefan> (mostly thanks to Dave's ucs-tables.el). Someone should Stefan> try and figure out the details. As for most functionality being in Emacs, yes, that's why I said I'd help refactor; relative to ucs-tables.el the contribution is all UI. My duplication[1] of ucs-tables is straightforward, not terribly efficient code; all the meat is devoted to the question of "how do we know which coding systems to offer the user". Specifically I address the issues of preferred unibyte systems and preferred universal systems described above. Footnotes: [1] XEmacs 21.5 has built-in support for Unicode. The UCS tables are loaded at startup from (a local copy of) the Unicode Consortium tables, and an API is provided to reload if desirable. The code predates the release of Emacs 21, and so is different from ucs-tables.el, unfortunately. The duplicative parts are for 21.4. -- ke@suse.de (work) / keichwa@gmx.net (home): | http://www.suse.de/~ke/ | ,__o Free Translation Project: | _-\_<, http://www.iro.umontreal.ca/contrib/po/HTML/ | (*)/'(*)