From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Stefan Monnier" Newsgroups: gmane.emacs.devel Subject: Re: lisp/ChangeLog coding system Date: Mon, 29 Apr 2002 09:31:18 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: <200204291331.g3TDVJX19627@rum.cs.yale.edu> References: <86g01i8qoa.fsf@gerd.dnsq.org> <200204272241.g3RMfqI05559@aztec.santafe.edu> <6923-Sun28Apr2002212223+0300-eliz@is.elta.co.il> <87znzn48el.fsf@tleepslib.sk.tsukuba.ac.jp> <200204290155.g3T1tT814296@rum.cs.yale.edu> <87it6a3frc.fsf@tleepslib.sk.tsukuba.ac.jp> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1020087236 25376 127.0.0.1 (29 Apr 2002 13:33:56 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 29 Apr 2002 13:33:56 +0000 (UTC) Cc: "Stefan Monnier" , Eli Zaretskii , 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 172BHv-0006bB-00 for ; Mon, 29 Apr 2002 15:33:55 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 172BLg-0006OS-00 for ; Mon, 29 Apr 2002 15:37:49 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 172BHQ-0005W7-00; Mon, 29 Apr 2002 09:33:24 -0400 Original-Received: from rum.cs.yale.edu ([128.36.229.169]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 172BFS-0004VH-00 for ; Mon, 29 Apr 2002 09:31:22 -0400 Original-Received: (from monnier@localhost) by rum.cs.yale.edu (8.11.6/8.11.6) id g3TDVJX19627; Mon, 29 Apr 2002 09:31:19 -0400 X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4 Original-To: "Stephen J. Turnbull" Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:3400 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:3400 > >>>>> "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). As Miles said, you can call (ucs-unify-8859 t) to unify the latin charsets when saving a file. Better yet: you don't need to do it any more because it's now the default behavior. > 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, That's what happens right now. > 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. A German would get a prompt where iso-8859-2 and utf-8 should be near the beginning of the list of coding-systems she can choose from. > And what's a "non-MIME coding system"? I don't know. All I know is that it's used when sorting coding-systems so that the list has more "likely" coding systems at the beginning. I think it's also used to choose more user-friendly names when a coding-system has several aliases (such as mule-utf-8 and utf-8. Don't ask me why the coding-system is called `mule-utf-8' and why `utf-8' is only an alias, tho). > 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. I'm beginning to understand, thank you, Stefan