From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/66260 Path: news.gmane.org!not-for-mail From: "Miles Bader" Newsgroups: gmane.emacs.gnus.general Subject: Re: Emacs unicode merge changes to Gnus Date: Thu, 7 Feb 2008 07:44:36 +0900 Message-ID: References: <61r6fqbyuv.fsf@fencepost.gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1202337917 29575 80.91.229.12 (6 Feb 2008 22:45:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 6 Feb 2008 22:45:17 +0000 (UTC) To: "Reiner Steib" , "Miles Bader" , ding@gnus.org Original-X-From: ding-owner+M14751@lists.math.uh.edu Wed Feb 06 23:45:37 2008 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by lo.gmane.org with esmtp (Exim 4.50) id 1JMt1M-0003pi-SS for ding-account@gmane.org; Wed, 06 Feb 2008 23:45:37 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1JMt0b-0008GN-2q; Wed, 06 Feb 2008 16:44:49 -0600 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1JMt0Y-0008Fr-Tm for ding@lists.math.uh.edu; Wed, 06 Feb 2008 16:44:46 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtp (Exim 4.67) (envelope-from ) id 1JMt0S-0005x6-OX for ding@lists.math.uh.edu; Wed, 06 Feb 2008 16:44:46 -0600 Original-Received: from an-out-0708.google.com ([209.85.132.250]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1JMt0W-0004Nt-00 for ; Wed, 06 Feb 2008 23:44:44 +0100 Original-Received: by an-out-0708.google.com with SMTP id c8so1013991ana.45 for ; Wed, 06 Feb 2008 14:44:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=eTXsmiNwl8UR3zIX7n/sgCGSszod1o+ZNNjAAEysJKw=; b=iysnO0UDZ92MOFumKY+Tca+CQn8hWSJGb/fbjnyfB13q2iFafLA0XvMXvW/VC5uScS8+tW/Cih9Rrztbi9VT7teik/5CRKTlWddoURdUZ9FT4IEHMu1nHBCzJAR31NMES95EV4UQLDOvrIFaEseTeF24FaOgOpnqodSVh/hp2qs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=jth9AfYJIfrpZuX0aw+ExJPlLPPRsbzKOvdboRew7apU0IGl7P5U8TGgbFVUDpe6elaMpHYqw+vTblYOt088aPim1LXw69cpLvhtI7hzIcHrTp/15KYb5UMoaaeRHScHfyC9L5k1oj8mK9X8na8vBVfOdn08CBe0WXZKMnuugWU= Original-Received: by 10.100.239.11 with SMTP id m11mr22091639anh.70.1202337876493; Wed, 06 Feb 2008 14:44:36 -0800 (PST) Original-Received: by 10.100.4.19 with HTTP; Wed, 6 Feb 2008 14:44:36 -0800 (PST) In-Reply-To: Content-Disposition: inline X-Google-Sender-Auth: c93a19df8d734463 X-Spam-Score: -2.6 (--) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:66260 Archived-At: > - (let ((coding-system-for-read gnus-ding-file-coding-system)) > - (gnus-load ding-file)) > + (gnus-load ding-file) ... > - (princ ";; -*- emacs-lisp -*-\n") > + (princ (format ";; -*- mode:emacs-lisp; coding: %s; -*-\n" > + gnus-ding-file-coding-system)) ... > This could cause problems for people switching (from Emacs 23) to > Emacs <= 22 (or XEmacs). AFAICS, Emacs 21 and 22 simply ignore the > cookie if the coding is unknown. I'd expect problems for people using > e.g. non-ASCII group names. Any ideas how to fix this problem? It seems like this change wouldn't affect that case either way: if they switch emacs to an old version, and gnus-ding-file-coding-system is something unknown, and they actually have some non-ascii chars in there, they're screwed, whether with the old code or the new code. There's a case where the old code could work better, if the file is written with utf-8-emacs (the default now, I guess), and the switched-to-system happens to use a coding system of utf-8 which is largely compatible; for Emacs 21, this won't happen (the switcher is just plain screwed in this case, no matter what, I think), as Emacs 21 doesn't support utf-8. Now, the new code could also work (more properly, instead of by accident) in the switching-to-emacs-22 case, if Gnus used a coding: tag of "utf-8" instead of "utf-8-emacs" when possible. In any case, I think it definitely should always write a coding: tag, and clearly using it is the way for the future. To handle the switch-to-emacs-22 case, it could try to use "coding: utf-8" except when that can't encode something. The only case I know of when utf-8-emacs works but utf-8 doesn't, is when you have random binary bytes embedded in the file, in which case I think the proper thing to do is say "don't an idiot." It seems to me that the switch-to-emacs-21 case is going to break no matter what (unless you only use ascii), so there shouldn't be any effort expended to fix it. -Miles -- Do not taunt Happy Fun Ball.