From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/55215 Path: main.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.gnus.general Subject: Re: spam.el: exiting groups is really really slow Date: Fri, 12 Dec 2003 16:45:42 -0500 Organization: =?koi8-r?q?=F4=C5=CF=C4=CF=D2=20=FA=CC=C1=D4=C1=CE=CF=D7?= @ Cienfuegos Sender: ding-owner@lists.math.uh.edu Message-ID: <4noeud90c9.fsf@collins.bwh.harvard.edu> References: <4ny8u43vk3.fsf@lockgroove.bwh.harvard.edu> <7coeuzzg6c.fsf@nature.tsukuba.ac.jp> <4nad6j87dm.fsf@lockgroove.bwh.harvard.edu> <87r7zvxcqe.fsf@everett.mit.edu> <4nptf8fe66.fsf@lockgroove.bwh.harvard.edu> <87ad6bsadl.fsf@emacswiki.org> <4nbrqrhxvn.fsf@lockgroove.bwh.harvard.edu> <4n1xrcl1bc.fsf@collins.bwh.harvard.edu> <87llpib9ci.fsf@emacswiki.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1071265729 3414 80.91.224.253 (12 Dec 2003 21:48:49 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 12 Dec 2003 21:48:49 +0000 (UTC) Cc: David Z Maze , Hiroshi Fujishima , ding@gnus.org Original-X-From: ding-owner+M3755@lists.math.uh.edu Fri Dec 12 22:48:45 2003 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AUv9R-0004EH-00 for ; Fri, 12 Dec 2003 22:48:45 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 1AUv7g-00053L-00; Fri, 12 Dec 2003 15:46:56 -0600 Original-Received: from justine.libertine.org ([66.139.78.221] ident=postfix) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1AUv7X-00053A-00 for ding@lists.math.uh.edu; Fri, 12 Dec 2003 15:46:47 -0600 Original-Received: from clifford.bwh.harvard.edu (clifford.bwh.harvard.edu [134.174.9.41]) by justine.libertine.org (Postfix) with ESMTP id C45363A003B for ; Fri, 12 Dec 2003 15:46:45 -0600 (CST) Original-Received: from collins.bwh.harvard.edu (collins [134.174.9.80]) by clifford.bwh.harvard.edu (8.10.2+Sun/8.11.0) with ESMTP id hBCLji702191; Fri, 12 Dec 2003 16:45:44 -0500 (EST) Original-Received: from collins.bwh.harvard.edu (localhost [127.0.0.1]) by collins.bwh.harvard.edu (8.12.9+Sun/8.11.0) with ESMTP id hBCLjiuB007881; Fri, 12 Dec 2003 16:45:44 -0500 (EST) Original-Received: (from tzz@localhost) by collins.bwh.harvard.edu (8.12.9+Sun/8.12.9/Submit) id hBCLjgSm007876; Fri, 12 Dec 2003 16:45:42 -0500 (EST) Original-To: Alex Schroeder X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6;d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Followup-To: Alex Schroeder , David Z Maze , Hiroshi Fujishima , ding@gnus.org In-Reply-To: <87llpib9ci.fsf@emacswiki.org> (Alex Schroeder's message of "Fri, 12 Dec 2003 11:48:13 +0100") User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (usg-unix-v) Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:55215 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:55215 On Fri, 12 Dec 2003, alex@emacswiki.org wrote: > Ted Zlatanov writes: > >>> I'm OK with utf-8-emacs, iso-2022-7bit, or anything else. >> >> I haven't seen a response, maybe due to my MTA problems recently. >> Did you have a preference? Do you want me to make the change? > > Yeah, real-life problems, and being unsure of what the best solution > is. There was another coding-system question on xemacs-design > lately; the discussion was for or against coding cookies (and I > agree with the position that says iso-2022-jp is better than coding > cookies, because all iso-2022 systems (including emacs-mule, by the > way) are basically bytes with embedded escape sequences indicating > what coding system is being used. Maybe it's best to give these choices: - none - emacs-mule - utf-8 - user-specified And make emacs-mule the sensible default. I'm just guessing though, I don't know much about Emacs coding systems. > What this means for XEmacs users that switch from mule to non-mule I > don't know. I *think* it means that they have to throw away their > spam-stat file. Is that ok with you? We can always provide a backwards-portability function, no? Ted