From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/72863 Path: news.gmane.org!not-for-mail From: Richard Riley Newsgroups: gmane.emacs.gnus.general Subject: Re: splitting working now : some issues/questions Date: Sun, 10 Oct 2010 18:28:10 +0200 Organization: aich tea tea pea dicky riley dot net Message-ID: References: <9i4ocwyc69.fsf@news.eternal-september.org> <87wrpstwvz.fsf@lifelogs.com> <8uy6a67ugj.fsf@news.eternal-september.org> <87sk0ek21m.fsf@lifelogs.com> <87eibyjuyq.fsf@lifelogs.com> <8762xajdh0.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1286728115 16330 80.91.229.12 (10 Oct 2010 16:28:35 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 10 Oct 2010 16:28:35 +0000 (UTC) Cc: ding@gnus.org To: Ted Zlatanov Original-X-From: ding-owner+M21235@lists.math.uh.edu Sun Oct 10 18:28:33 2010 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.69) (envelope-from ) id 1P4ylF-00082U-1P for ding-account@gmane.org; Sun, 10 Oct 2010 18:28:33 +0200 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 1P4yl9-0002HH-2Z; Sun, 10 Oct 2010 11:28:27 -0500 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1P4yl7-0002H0-Lw for ding@lists.math.uh.edu; Sun, 10 Oct 2010 11:28:25 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtp (Exim 4.72) (envelope-from ) id 1P4ykw-0003L1-MK for ding@lists.math.uh.edu; Sun, 10 Oct 2010 11:28:25 -0500 Original-Received: from mail-bw0-f44.google.com ([209.85.214.44]) by quimby.gnus.org with esmtp (Exim 3.36 #1 (Debian)) id 1P4ykv-0002CS-00 for ; Sun, 10 Oct 2010 18:28:13 +0200 Original-Received: by bwz14 with SMTP id 14so931318bwz.17 for ; Sun, 10 Oct 2010 09:28:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject :organization:references:date:in-reply-to:message-id:user-agent :mime-version:content-type; bh=Hom9MhLnjTBz8Rexqjiypk4Rjc0o8c9O1hjFQdd6O1s=; b=wgYaguIWy/714fLymhxZeqD8j3tDl5Ro1YkaER51OOsUW//zCN4MSP7ST5ejsEr7LY hrDazIlVU98V7dl2/QD6vlrqpPjzxev+GjlArVP5DnS5hzkMObKowZ/yRXBOUxaHKCLc S3B2VGQUxiqBdiYcAHSNKGGK32aluP2JibVOE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:cc:subject:organization:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=NwfI2OnGIqBltv9DjhjrxoyW6d0CAtPYqtBBYbP0MpuKlYH8jkA42wa0sJP59AoAhi NEbOJVs7sN5sIqpXekUfhyzC/E1jVTiQYHCD89eFMCKwXukXvOu7oAWDJuVqnnIHyCX7 xbP2/KDAeoWd+rPTdwZLllk3P9j5EO7igqMvg= Original-Received: by 10.204.79.81 with SMTP id o17mr4338511bkk.103.1286728093088; Sun, 10 Oct 2010 09:28:13 -0700 (PDT) Original-Received: from localhost ([85.183.18.158]) by mx.google.com with ESMTPS id y19sm4692559bkw.6.2010.10.10.09.28.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 10 Oct 2010 09:28:12 -0700 (PDT) In-Reply-To: <8762xajdh0.fsf@lifelogs.com> (Ted Zlatanov's message of "Sun, 10 Oct 2010 10:04:43 -0500") User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux) X-Spam-Score: -2.0 (--) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:72863 Archived-At: Ted Zlatanov writes: > On Sun, 10 Oct 2010 12:17:25 +0200 Richard Riley wrote: > > RR> Ted Zlatanov writes: >>> For spam-split and general splitting, actually I have wanted for a long >>> time the group name to be qualified, but currently splitting only works >>> to the same server. To keep with the Gnus conventions, I'd prefer to >>> keep group names qualified whenever poassible. > > RR> Yes, but why? > > 1) to keep Gnus consistent Thats my whole point : Its not consistent. Some places need it qualifying others dont. And if you dont it defaults to the current server. This is NOT how its done here. And that saw my mail suddenly vanish and totally hog my network and cause my gmail bandwidth for a day to run out. Admittedly that was in the context of the INBOX spam handling bug causing ALL messages to be reprocessed. > > 2) to avoid inconveniencing the people who have been using spam.el for > many years now Since a lot is changing and certainly my entire spam set up had to be rewired as a result of the way INBOX was dealt with. Which due to lack of feedback I assumed was redesign as opposed to bugs. It seems to have settled back now and was indeed bugs. > > 3) because it uses the Gnus "move article" facility, which uses > qualified names So it can qualify it before calling that? At least some other vars are server local. "because thats the way it is" hardly encourages debate. It makes sense to me at least that a folder name UNQUALIFIED should be local to that server. In fact it seems so obvious I wonder why we debate it ;) > > RR> If you are working a group in a certain server and something > RR> operates on that server, unqualified makes a lot more sense and is > RR> simply more convenient keeping in mind the manual talking about not > RR> qualifying in other such settings. "spam" means "spam" folder on > RR> this server, "nnml+otherserver:spam" means something else. > > Well, spam.el has been around for a while now (since 2002). You are the > first person to say they want the move destination to be unqualified. Where did I say that? I said I would have *expected* it to be local because of other such settings which are local. Why qualify something when on a server each and every time? If you want it moved elsewhere on another server then qualify it. A huge hurdle with convincing people to use Gnus I find in #emacs for example are such inconsistencies and the general difficulty with customisation. You are aware such a mindset exists I assume? It's not easy. I am only conveying my views here on how it would make more sense to be done another way. Of course I understand reluctance to change as well. The current changes are bordering on miraculous and make Gnus a wonderful client. > So while it may be that all the other users have been annoyed by that > but kept quiet, it's more likely it's not a big deal. So unless I hear > from more people supporting your view, I'd rather keep the status quo. Fine if thats the way you see it. The improvements done to Gnus suggest that "because thats the way its always been" are not the only criteria under consideration while development and improvements take place. I'll wave the white flag now. cheers for the feedback r.